CAS secure cookie

Harippriya Sivapatham hari_forums at yahoo.com
Thu Aug 30 11:35:08 EDT 2007


Hi Scott,
  Many thanks for your quick reply. I thought more about what you said and I would like a small clarification. To reiterate my scenario with an example - there are two clients http://client1 and http://client2 that point to the same CAS server. User logs into http://client1. The client1 UI programatically accesses http://client2/test.jar . 
   
  So, my questions are:
  - I found that ticket generated for the two client URLs are different (perhaps since the service url is different?). On the same principal, I would assume that the session cookie generated for the two will be different. Is this assumption correct?
   
  - Is there any other way of preventing the redirect to the cas login URL when the client2 url is accessed for the very first time? 
   
  - Can I use the proxy mechanism here to solve the issue I have?
   
  Thanks!!!
  Hari
  

Scott Battaglia <scott.battaglia at gmail.com> wrote:
  Hari,

Whenever a user attempts to access a secure application, it should redirect the user to CAS (if the user doesn't not have an already existing session with that application).  The user will either need to sign in if he hasn't already and then he will be redirected back to the calling application with a "ticket" that can be validated by the application. 

Each time the user is redirected to the CAS login page, the secure TGT cookie is sent to the CAS server (and only the CAS server) to attempt to re-establish a single sign on session (so the user isn't prompted for credentials again). A user will only be sent to the CAS login page if the secure application determines that the user needs to authenticate. 

The cookie can only be accessed from the CAS server.  There should be a method on the request object to retrieve cookies.  No one else should ever see that cookie.

If you need to protect an applet, you should protect the HTML page that exposes the applet.  You can then protect the applet by using a proxy ticket and pass that ticket as a parameter to the applet (and thus avoid the redirect). 

Hope that helps.
-Scott

  On 8/29/07, Harippriya Sivapatham <hari_forums at yahoo.com> wrote:     Hello,
  I have been looking into CAS for the past few days. My setup is that I have a tomcat that has the CAS server and multiple CAS clients. I have two questions that I hope someone could shed some light on. 
  - After the user logs in, I understand that the secure cookie is placed in the browser. Who validates this cookie sent with subsequent requests? In other words, will every client request be sent to the login url and then the requested content served? If yes, I dont see these transactions in the access log as a 302 redirect. 
  - Is there a programatic way of reading the cookie in a JSP. I tried request.getHeader("Cookie") but that did not help. The reason I ask is to handle the case of multiple CAS clients pointing to the same CAS server. If user logs into one CAS client and then tries to access another client, he will be redirected (302 response returned) to the login URL. This works as expected and the user is not challenged. However, in my case, an applet is the one requesting and it is not able to handle these 302 responses. I am trying to find a way to avoid this redirect, perhaps by sending the cookie information. 
   
  Thanks a lot for your help
  Hari
  
  
---------------------------------
  Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.   

_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas





-- 
-Scott Battaglia

LinkedIn: http://www.linkedin.com/in/scottbattaglia _______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas


       
---------------------------------
Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel and lay it on us.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20070830/41fe5ca3/attachment.html 


More information about the cas mailing list