Bryan Wooten, You can share this filter?
On Thu, Feb 24, 2011 at 7:15 PM, David Wolowicz <[email protected]> wrote: > >I'll say again there are fundamental obstacles with this approach. > > Yes I agree. Although, for us they are not an issue. > > >> We are doing this now and it's a mess. > >> ... > >> Right now, we are catching the logout with our load balancer, then > re-routing it to a script that replicates it to the servers related to the > service. > > >This is not the strategy we are leaning toward. (Maybe I described it > poorly in haste.) > > Sorry by "We" I meant UVic, not JASIG. > > > > Dave Wolowicz > Manager of Web Services > University of Victoria Systems > [email protected] | (250) 721-6117 > > Call me toll-free over the internet: UVic-6117 > > > -----Original Message----- > From: Marvin Addison [mailto:[email protected]] > Sent: February-24-11 6:41 AM > To: [email protected] > Subject: Re: [cas-user] Clustered CAS client logout request > > > I'd like to see the servers defined in the Service Manager. That way you > would have a Service with it's URL, and then (n) servers with their direct > URLs. > > I'll say again there are fundamental obstacles with this approach. > First, there is the problem that not all load balanced setups allow > direct access to the individual nodes servicing the cluster; for > example, they may be on a private network. The second and likely more > common problem is one of hostname verification. Even if the nodes are > accessible, the CN of the SSL certificate on the virtual IP is almost > certainly different from the hostnames of the individual nodes, e.g. > https://service.vt.edu maps to https://service-n.subdomain.vt.edu. > While we could allow pluggable hostname verification strategies on the > server like we do with the Java client, it's yet one more obstacle to > overcome. > > > We are doing this now and it's a mess. > > ... > > Right now, we are catching the logout with our load balancer, then > re-routing it to a script that replicates it to the servers related to the > service. > > This is not the strategy we are leaning toward. (Maybe I described it > poorly in haste.) We are leaning toward a clustered state store for > the client, e.g. JBossCache, where each node in the cluster consults > the state store to determine the present authenticated state. When > _any_ node receives the LogoutRequest message, it looks up the entry > in the shared state store and destroys it. There are some potential > problems in that lookup, but they seem soluble in theory. Then when > the node holding the session receives its next request from the user, > it checks the shared state store, can't find the entry, and marks the > session as having ended and redirects to CAS for authentication. > > > If we could help in some way to get this feature in, please let me know. > > I created https://issues.jasig.org/browse/CASC-114 a long time ago to > help get started on a solution for the Java client. Anyone is welcome > to provide a patch or suggest other implementations. Maybe we need a > general placeholder CAS Server issue for "Support for Clustered Single > Sign Out". I don't see such an issue at > https://issues.jasig.org/browse/CAS, but I didn't do an exhaustive > search. > > 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 > > -- 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
