Hacking CAS to get simple federated SSO

[Scott Battaglia]

You should (and I apologize in advance for the strength of this statement)
NEVER EVER share your TGT Identifier (i.e. the cookie) with any one besides
the CAS server that specifically issued the cookie (which is why the cookie
restrictions are in place).

The TGT identifies your single sign on session with the CAS server without
forcing you to re-enter your username/password.  If someone was to obtain
that identifier, they could impersonate your session.  Which would be a very
bad thing.

-Scott
-- 
-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Thu, Mar 27, 2008 at 1:16 PM, Christopher Brooks <cab938 at mail.usask.ca>
wrote:

> Hi,
>
> Thanks for the reply.
>
> >SECURITY CONCERN
> >--------------------------------------------------------------------
> >As for your questions, I would abstain from having the CASTGC available
> >to any of your application servers.  This allows someone who compromises
>
> Right, actually, I was only going to have the CASTGC available to the
> other
> CAS clients.  So my apps would be behind my CAS client, which would be
> able
> to get the cookies (CASTGC's) created by other cas clients out there.
>
> >CASTGC to NETID
> >----------------------------------------------------------------------
> >CAS uses the CASTGC to validate whether the user is logged in or not.
>
> Ok, this is good to know.  So if I share the CASTGC from cas client a to
> cas
> client b by way of a cookie (TCG), cas client b at least knows that this
> person is logged in.  The docs say that a TGC contains a string that
> identifies a ticket granting ticket, but the TGT isn't really mentioned
> anywhere else, so I'm not sure of its importance.
>
> On one of our CAS 2 apps, I log in, then punch in a different URL that is
> protected with that same CAS client.  There is no service ticket that I
> can
> see being passed (either as a cookie or as a URL parameter).  Instead, all
> our filter gets is a couple of cookies (a sessionid and the castgc).  If I
> get rid of the sessionid it still logs me in, so the filter must be using
> the castgc to let me into the app?
>
> So....
>
> Can I take a CASTGC and validate it's authenticity by opening up a request
> to the CAS client who provided the cookie, then have it redirect me to a
> service that contains the username of the individual?  Thus my second CAS
> server can validate both that they have been logged in as well as what
> their
> netid is?
>
> Assuming this works, can anyone suggest in the code where:
>
> 1. I should change the cookie params to be more lenient (e.g. to allow my
> second CAS client to be added as a host that the ticket should be given
> too)
> 2. A manner of getting the netid from a service ticket (which I should get
> when I am redirected after I present the TGC).
>
> Regards,
>
> Chris
> --
> Christopher Brooks
> PhD Student, ARIES Laboratory
>
> Email: cab938 at mail.usask.ca
> Web: http://www.cs.usask.ca/~cab938 <http://www.cs.usask.ca/%7Ecab938>
> Mail: Christopher Brooks, MSc
>      Department of Computer Science
>      110 Science Place
>      Saskatoon, SK
>      S7N 5C9
>
>
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080327/9c6ac70a/attachment.html