Thanks & Regards,
Gokula
Sent from BlackBerry, please ignore typo.
________________________________
From: Gokula Krishnan P
To: [email protected]
Cc: kmpradeep (SAAS); Raja Mohan
Sent: Mon Jan 18 09:39:37 2010
Subject: RE: [cas-user] Handling CAS logoutofservices
Hi Scott,
Thanks again, since we have hosted secure pages (that need authentication) both
in http and https, passing jsession id in URL definitely causes security
vulnerability.
Therefore I would request you to suggest us an work around to accomplish Single
Logout having the constraints of cookie based load balancing and non-clustered
environment (Non-session replication setup).
Thanks & Regards,
Gokula
From: Scott Battaglia [mailto:[email protected]]
Sent: Friday, January 15, 2010 8:18 AM
To: [email protected]
Subject: Re: [cas-user] Handling CAS logoutofservices
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]<mailto:[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]<mailto:[email protected]>
<[email protected]<mailto:[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]<mailto:[email protected]>]
Sent: Tuesday, January 12, 2010 10:59 PM
To: [email protected]<mailto:[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]><mailto:[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]><mailto:[email protected]<mailto:[email protected]>>]
Sent: Tuesday, January 12, 2010 10:06 AM
To:
[email protected]<mailto:[email protected]><mailto:[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]><mailto:[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]><mailto:[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
;
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
;
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
;
[email protected]<mailto:[email protected]><mailto:[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]><mailto:[email protected]<mailto:[email protected]>>
as:
[email protected]<mailto:[email protected]><mailto:[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]><mailto:[email protected]<mailto:[email protected]>>
as:
[email protected]<mailto:[email protected]><mailto:[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]><mailto:[email protected]<mailto:[email protected]>>
as:
[email protected]<mailto:[email protected]><mailto:[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
