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=3D22FCE59C96D860823828FAA2EA6FD84B please 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
