> the best practice is to hold the client responsible for correctly managing > the logout requests > (e.g. by rebroadcasting).
There's no best practice; there are only options and all of them require a fair bit of customization. I should note that CAS 4.0 will support a beta front-channel single sign-out, which will be compatible with clustered apps since it will leverage the user agent to facilitate log out, so it will honor the same-source requirement of a load balancer to route requests to the appropriate nodes. There is no corresponding support in the clients yet for that feature, but it would presumably be relatively easy to implement (compared to rebroadcasting.) > Unfortunately, we cannot change the client application; besides, the official > Java client solution > (CASC-142) is not yet available. The patch attached to CASC-142 has been tested and works as intended, as I mentioned on the issue. Attempting to solve this problem requires a fair bit of work regardless; might as well build on top of existing code. > Could there arise potential problems (in particular, security-related) if we > modified the CAS > Server to distribute the logout requests? E.g. by using a mapping table > myclusteredapp -> myclusteredappnode1, myclusteredappnode2 > to distribute a logout request I'd recommend you review https://issues.jasig.org/browse/CAS-1292 before striking out on your own with another server-side solution. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
