The issue also depends on whether you're clustering sessions or not. In theory if you're clustering sessions, there's less work to do (though I haven't tried it so I reserve the right to revoke that statement :-)). You merely need to make the map between session id and ST distributed. If sessions aren't clustered, you have to broadcast the message internally (which isn't a big deal) but it would require either multi-cast or you to configure all the nodes to know about each other, or have a way of finding out about each other.
On Wed, Jul 7, 2010 at 10:29 PM, Adam Rybicki <[email protected]> wrote: > Bryan, > > You are right--the SSOut POST may arrive at a cluster node that did not > handle that session. Looking at the source of the Jasig CAS client for > Java, I can see that its implementation of the SSOut filter will not > work on a clustered application. Even if you came up with a distributed > implementation of the SessionMappingStorage, the interface requires that > the mapping is done between service ticket and HttpSession. HttpSession > only works on the app server that created it. > > I don't mean to pick on the Jasig CAS client for Java. Few CAS clients > have support for SSOut. > > The Jasig CAS client for Java had to solve a similar issue when > receiving proxy granting tickets. Because those are just simple > strings, a distributed PGT storage map is sufficient. Currently, > Ehcache and memcache are supported. > > One possible way to enhance the Jasig CAS client for Java would be to > "broadcast" the SSOut event to all cluster nodes, and the "correct" node > would handle the event. Not elegant, but it would work. > > Another would be to have a simple distributed storage map, very similar > to that for the PGTs, and store a mapping between the ST and the cluster > node that created the session from the ST. This way, if the node > receiving the SSOut event was correct, it would operate as it does > today. Otherwise, it would know which cluster node to forward the SSOut > POST to. This would be a little more code, but no "shooting in the dark > hoping to hit the right node." ;-) > > The above paragraph could create issues with SSL due to the > hostname/cert name mismatches... Let's not go there for now. > > As you may have guessed by now, this is not an easy problem to solve. ;-) > > Adam > > Bryan Wooten wrote: > > > > I was wondering how (of if) single signout will work for applications > > that are load balanced (Sun App Server proxy with load balancer plugin). > > > > > > > > It seems to me the single signout may not work because the sign out > > POST CAS makes will be directed to the proxy and it may forward the > > POST to other application server and not the original application server. > > > > > > > > Does this make sense? Is this even designed to work in load balance > > environments? > > > > > > > > Thanks for any feedback, > > > > > > > > Bryan Wooten > > > > > > > > [email protected] > > > > Work: 801.585.9323 > > > > Cell: 801.414.3593 > > > > > > > > -- > > 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 > -- 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
