Hi scott, Could you please help me on the issue. I would appreciate your quick response.
Thanks & Regards, Gokula Sent from BlackBerry, please ignore typo. ----- 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=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]<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 **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** -- 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
