The cookie is not accessible to the piece that calls logout (though if you send the jsession id, its the same thing). I don't know of any current issues with passing the jsession id like you're doing, assuming you're using SSL.
Cheers, Scott On Wed, Jan 13, 2010 at 10:14 AM, Gokula Krishnan P < [email protected]> wrote: > Hi Scott, > Thank you, I understood CAS Single Signout Filter would solve my problem by > storing the map of ticket and session id. Currently I am using CasClient > 2.0.11 so I need to upgrade to CasClient 3.1. > > One question, > Our current environment has cookie-based loadbalancer which would forward > the request based on the cookie name sufix (e.g. jsessionid.node1) which is > mapped to server instance/node. so is there any way logoutofservices would > pass the cookie as part of the request so that the request would reach the > relevent instance/node for session invalidation. > I request you to advice me the best possible approach. > > > Thanks & Regards, > Gokula > > ----- Original Message ----- > From: Gokula Krishnan P > To: [email protected] <[email protected]> > Sent: Wed Jan 13 06:53:29 2010 > Subject: RE: [cas-user] Handling CAS logoutofservices > > Hi Scott, > No I have not tried with CAS Single Sign Out Filter but I don't get what > you mean by the Listener with Spring Security. I have gone through the CAS > Single Sign Out filter implementation and I also understand Acegi > LogoutFilter does the same thing, the filter I am using is the extends acegi > logout filter. > Please provide me more information how this is going to solve my problem so > that I can try it out. It would be great if you could give me few URL links > to the documentations/implementations. I have come across an implementation > of single logout but with shared caching mechanism > https://confluence.ucdavis.edu/confluence/display/IETP/CAS+Single+Sign+Out > > Thanks in advance, > > Thanks, > Gokula > > ________________________________________ > From: Scott Battaglia [[email protected]] > Sent: Tuesday, January 12, 2010 10:59 PM > To: [email protected] > Subject: Re: [cas-user] Handling CAS logoutofservices > > Have you tried configuring the CAS Single Sign Out Filter and Listener with > Spring Security? > > > > On Tue, Jan 12, 2010 at 10:59 AM, Gokula Krishnan P < > [email protected]<mailto:[email protected]>> wrote: > Hi Scott, > Thanks for your response. > > We have n number of applications (Application-A, Application-B, … > Appication-n) integrated with CAS for SSO through acegi filters. All the n > applications are headed with acegi filter chain which is responsible for the > redirection of the requests to CAS if the user is not authenticated (if user > details not present in the security context holder). Once the user is > authenticated (principal details are available in security context holder) > all the consecutive requests to that application-A are never redirected to > CAS and its until the expiry of the application-A session. Say if the user > access application-B from same browser (New Tab) he is able to access > without providing the credential. If he wants to Signout of the SSO he > clicks on logout, the CAS (TGT) session is invalidated by CAS and > logoutofservices request is sent to application-A and application-B. But the > individual application (application-A, application-B) sessions needs to be > invalidated in order to stop the user from accessing the application-A or > application-B. Even if CAS SSO session (TGT) is invalidated the user will be > able to access the application-A and application-B until the session of the > applicationA/B is alive. Acegi never redirects the user to CAS for > authentication until the application-A/B session is alive. Therefore only > way out is to invalidate the application-A/B session so that the user will > be redirected to CAS for authentication. The invalidation of session > (session.invalidate()) is done by a LogoutFilter which is part of my acegi > filter chain. The logoutfilter identifies the request (if it is > logoutRequest) it executes a logic to invalidate that session. To invalidate > at particular session the request should be attached with session identifier > (either through cookie or url). That is the reason I am passing the > jsessionid as part of URL. If the logoutofservices happens through browser > the jsessionid cookie is sent by the browser to the server automatically. > > Please advice me the best possible approach. > > > Thanks & Regards, > Gokula > > From: Scott Battaglia [mailto:[email protected]<mailto: > [email protected]>] > Sent: Tuesday, January 12, 2010 10:06 AM > To: [email protected]<mailto:[email protected]> > Subject: Re: [cas-user] Handling CAS logoutofservices > > The CAS client doesn't need it in the url in order to work. Is there a > reason you put it in the URL? > > On Mon, Jan 11, 2010 at 9:29 PM, Gokula Krishnan P < > [email protected]<mailto:[email protected]>> wrote: > Hi, > Please can some one validate my approach and comment on pros/cons? > > > > Thanks & Regards, > Gokula > > Sent from BlackBerry, please ignore typo. > ________________________________________ > From: Gokula Krishnan P > To: [email protected]<mailto:[email protected]> > Cc: [email protected]<mailto:[email protected]> ; > [email protected]<mailto:[email protected]> ; > [email protected]<mailto:[email protected]> ; > [email protected]<mailto:[email protected]> > Sent: Mon Jan 11 10:15:06 2010 > Subject: Handling CAS logoutofservices > Hi Team, > > CAS Single Logout does a Http URL Connection to all the registered services > and does a logout request (SAML Post). The individual applications > invalidates the sessions identifying the logout request. > In order to identify the session of the user from the logout request (SAML > Post) we do a re-writing of jsessionid as part of service URL when the user > gets redirected to CAS login page. The service URL now contains jsessionid > and which is stored in CAS map. The CAS Login URL looks like > https://domain.com/cas/login?service=https://domain.com/secureapp/j_acegi_cas_security_check;jsessionid=3D22FCE59C96D860823828FAA2EA6FD84Bplease > note that the service URL contains jsessionid which will be used to > identify and invalidate the session in the individual application. > > This works as expect but I request you to validate the approach of > passing/re-writing jsessionid as part of service URL. If this approach has > security vulnerability, please explain and suggest the best approach for > Single Logout. > > Thanks in advance. > > > Thanks & Regards, > Gokula > > -- > > > You are currently subscribed to [email protected]<mailto: > [email protected]> as: [email protected]<mailto: > [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]<mailto: > [email protected]> as: [email protected]<mailto: > [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]<mailto: > [email protected]> as: [email protected]<mailto: > [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 > > -- 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
