TGT and security
Scott Battaglia
scott.battaglia at gmail.com
Thu Apr 26 08:14:14 EDT 2007
Unless you've modified the MVC portion of the CAS Server, CAS can ONLY read
Ticket Granting Tickets from a cookie (it doesn't check anywhere else).
Furthermore, applications themselves only know how to process Service
Tickets. So giving a protected application a Ticket Granting Ticket should
have no effect. A protected application can only validate a Service Ticket.
-Scott
On 4/26/07, Javier Leyba <xleyba at gmail.com> wrote:
>
> On 4/25/07, Andrew Petro <apetro at unicon.net> wrote:
> > Javier,
> >
> > [
> >
> > I discovered if I place this TGT in a browser url as a CAS
> > parameter I can access to a web as a validated user.
> >
> > ]
> >
> > TGTs are security-sensitive and should not be exposed. CAS goes to some
> > lengths to model these as "secure cookies" that will only be passed
> > between browser and the CAS server and only via SSL.
> >
> > Your CAS integrations should similarly guard TGTs as if they were
> > short-lived client-side SSL certificates, since in spirit, that's what
> > they are.
> >
> > In the typical case, one application authenticates via CAS to another
> > application via proxy ticket, in the context of a real end user SSO
> > interaction. If there's a CAS-using end user in the loop this is to be
> > preferred, and it results in applications not interacting with the TGT
> > (but instead having a PGT, which is also security sensitive and should
> > be appropriately protected from exposure).
> >
> > It is possible and has been done to use CAS to authenticate one
> > application to another outside the context of end users. Rutgers does
> > this in their WOLP (web online payment) system, about which I hope Scott
> > can say a few words. It's a use story that would be worth better
> > documenting in the CAS wiki.
> >
> > It's not clear that it's useful for your web application to parse and
> > use a TGT, since you can use whatever primary credentials authentication
> > method that authenticated to your application to CAS. TGTs exist for
> > end user convenience. Web applications are less impatient.
> >
> > Adding the IP address to the TGT probably doesn't add reliable security
> > -- remote address headers and IP addresses are in principle forgeable.
> > More important is to protect access to the TGT than to expose the TGT
> > and attempt heroics to keep the Adversary from using it once he's got
> > his nefarious hands on it.
> >
>
>
> Andrew
>
> Thanks for your reply.
>
> I'm not sure if I understand what you said or fi you understood my first
> mail.
>
> You talked about my webapp, but I've not a web application, I' ve
> desktop applications made with java that will use CAS SSon to validate
> users.
>
> So, my desktop app ask user for id/password, sent to webservices app,
> webservices app send it to CAS server, etc, etc trying to simulate the
> normal web application SSOn process.
>
> At the end of the process, CAS send to a browser a TGT, so my desktop
> app receives a TGT. And my desktop app need the TGT to further access
>
> When I've developing and testing my desktop app I discovered if I take
> the received TGT I can get access to the protected app from a browser.
>
> If I understand you, you mean my desktop app should try to make use of
> PGT in a scenario where I must avoid to allow my desktop app to
> validate directly to CAS to get access to another app.
>
> If this is the case, I wonder what will happen with the PGT if I put
> it on a browser url. Could I access to the protected end app as it was
> with the TGT ?
>
> Sorry if I appear a little bit confused, but I want to be sure how to
> plan the best scenario to refactor my SSOn CAS environment.
>
> Thanks in advance
>
>
> J
> _______________________________________________
> 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/20070426/9bbc8414/attachment.html
More information about the cas
mailing list