I looked at the issue. The issue assumes that (a) you're still using the session to store something (just not the assertion, but the String id) and that (b) there may be instances where you determine its "logged out" because an Assertion is missing from storage not because the session ended.
I'm not really concerned about (a). I'd be concerned if we broke the notion that doing session.invalidate() cleared everything out. On Thu, Jul 8, 2010 at 10:36 AM, Marvin Addison <[email protected]>wrote: > > The issue also depends on whether you're clustering sessions or not. > > We were under the very mistaken assumption that all that was necessary > to get single sign-out working in a clustered environment was to use > clustered session storage. How wrong we were. We're using > JBossCache-backed sessions on one of our J2EE webapps running on JBoss > and single sign-out doesn't work. > > > In theory if you're clustering sessions, there's less work to do... > > You merely need to make the map between session id and ST distributed. > > I think it's straightforward, but much needed work that needs to exist > in the near term. I think a generic facility for assertion storage > (AssertionStorage interface) that maintains that mapping is needed. > This would be analogous to the TicketRegistry facility in the server. > Most of the existing session-backed code could be easily reworked, and > cluster-aware storage backends including JBossCache and JPA could be > provided with the distribution in the future. I've created > https://issues.jasig.org/browse/CASC-114 to help track this feature. > > 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 > -- 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
