CAS secure cookie

[Scott Battaglia]

On 8/30/07, Harippriya Sivapatham <hari_forums at yahoo.com> wrote:
>
> 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?
>

I'm not sure which session cookie you are talking about.  The Servlet
container session for CAS is irrelevant (it only lasts 5 minutes).  The
Single Sign On Session cookie lasts for the duration of whatever you have
defined and should only be created once per browser session.

Each time a service uses CAS it will get its own one-time use ticket
(whether thats the same service or two different services).

- 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?
>

The only way to prevent it is to use  Proxy Authentication to have client1
retrieve  a Proxy Ticket for Client 2 on the user's behalf.

- Can I use the proxy mechanism here to solve the issue I have?
>

>From my quick look at it, it seems possible (though I looked at it before
the holiday so I may be remembering it wrong ;-)).

-Scott

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<http://us.rd.yahoo.com/evt=48252/*http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC>,
> > 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<http://us.rd.yahoo.com/evt=48516/*http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7+>and lay it on us.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20070904/10ae794b/attachment.html