Security leak in cas-client-java-3.0.0-rc1?

[Scott Battaglia]

The default expiration policy for a Service Ticket is X amount of time or 1
use.  The default ExpirationPolicy for a TGT is X amount of time.  However,
they are both customizable and you can replace them with various other
policies (i.e. we had an example of a throttling TGT one).  Regardless of
the fact that we allow you to modify them, the CAS spec still says that STs
are one time use.

In order to log out of CAS, a user agent needs to contact the /cas/logout
url.  Some applications do this by placing a link to the CAS logout on their
logout page (i.e. "Log out completely"). [an application session is
independent of the CAS session]  Other applications automatically send a
redirect.  However, the CAS client will never do it for you as the CAS
protocol has no concept of single log out.

-Scott

On 9/20/06, Jack Tang <himars at gmail.com> wrote:
>
> Hi Scott and Velpi.
>
> Thanks for your reply and it is clear :).
> And could you please answer my two other questions?
> 1. What's the TicketExpirationPolicy purpose? It has nothing to do with
> ST?
> 2. There should be a LogoutAction in the client right? in order to
> invalidate session and callback the server side to remove granting
> cookie?
>
> Appreciate your time.
> /Jack
>
> On 9/20/06, Scott Battaglia <scott.battaglia at gmail.com> wrote:
> > To expand on what Velpi said.  When a user requests access to an
> > application, they are redirected to CAS (and may or may not need to do
> > authentication, depending on if a single sign on session exists).  The
> CAS
> > server will generate a token, which we call a ST, and redirect the user
> back
> > to the application, appending the token to the query string.  The
> > application will then take this token and validate it with the CAS
> server,
> > and then obtain the NetId of the user who wishes to use the
> application.  At
> > this point, the application would associate the user with this session
> (we
> > do this by placing the Assertion in the session).  Since the user has
> been
> > authenticated there would be no reason to keep validating a ticket (plus
> its
> > impossible since STs are one time use).  This object in session tells
> the
> > application the user has already been authenticated and there is no
> reason
> > to redirect them to CAS for authentication.
> >
> > -Scott
> >
> > On 9/19/06, Velpi <velpi at industria.be> wrote:
> > >
> > > > I guess the designer's purpose is taking off the pressure of CAS
> > > > server, but it make security issue.  Above code means the assertion
> is
> > > > always validate regardless the ST in ticket cache is expired or not
> > > > unless session is timeout. Another issue is the LogoutAction in CAS
> > > > server side should callback to invalidate the session.
> > > >
> > > > My proposal is put the ST in session and validate every time in
> order
> > > > to keep the security works.
> > >
> > > You can only validate an ST once (normally), so you need to store
> > > something
> > > *else* (in session) to create a useful security context. The assertion
> is
> > > only
> > > stored (in the session) when the validation has succeeded. Since
> nobody
> > > else is
> > > supposed to be able to mess with the server-side-session this should
> not
> > > cause a
> > > security problem.
> > >
> > > [please correct me if I'm wrong]
> > >
> > > -- Velpi
> > > _______________________________________________
> > > Yale CAS mailing list
> > > cas at tp.its.yale.edu
> > > http://tp.its.yale.edu/mailman/listinfo/cas
> > >
> >
> >
>
>
> --
> Keep Discovering ... ...
> Copenhagen Spirit =
> ¸ß¶ÈµÄÖÇÁ¦»î¶¯¡¢´óµ¨µÄÉæÏÕ¾«Éñ¡¢Éî°ÂµÄÑо¿ÄÚÈÝÓë¿ì»îµÄÀÖÌìÖ÷ÒåµÄ»ìºÏÎ
>
>
>
> _______________________________________________
> 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/20060920/91cb5806/attachment.html