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]> 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]] > Sent: Tuesday, January 12, 2010 10:06 AM > To: [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]> 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] > Cc: [email protected] ; [email protected] ; > [email protected] ; [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] 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 > > -- 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
