>> It seems like the answer to your Single Sign Out issue in a load balanced >> environment is fairly simple. >> Use a shared session mechanism instead of using sticky sessions for your >> load balanced servers.
> This is incorrect. Since the request is sourced differently from the CAS > server, it naturally does not contain the > session identifier needed to load the session from _any_ store, shared or > otherwise. > Please review the patch I referenced; it's one potential solution that has > been thoroughly tested. > While shared storage is part of the solution, it's not session storage alone > that needs to be shared. We've also implemented something like what you are describing (unfortunately not general purpose). The CAS client already enables you to plug in the storage method for the ST->JSESSIONID mapping. We simply store that mapping in the same noSQL DB that holds the shared sessions. When the Single Signout filter gets invoke on any node of the cluster, it simply looks up the session record via the referenced by the ST and invalidates the session. This is all done on the CAS client side with no changes in CAS. M -- You are currently subscribed to cas-user@lists.jasig.org as: david.oh...@emc.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
