[cas-dev] expiration policy using the global last access time and the CAS 'final' policy

[Scott Battaglia]

On Mon, Jun 9, 2008 at 10:36 AM, Ralf Lorenz <ralf.lorenz at mms-dresden.de>
wrote:

> Hi there,
> we're working on a project using CAS and with the SLO-feature provided by
> CAS we're
> not quite satisfied.
> Even SAML only discusses the case of an user logout action. In that case
> CAS works fine
> which is sending a logout request (saml like) to each client (service).
>
> But what about the session timeout issue? What if one of the client
> sessions or even
> the TicketGrantingTicket is timed out?


We made a conscious decision that the timeout of an individual application
would not affect the global session (since no one should have acesss to do
anything to your global session besides you and CAS).  That's by design.
However, if a TicketGrantingTicket expires it will notify the application
(so if a user explicitly logs out or the TGT is expired, notification will
be sent).


>
> Luckily we found your ExpirationPolicy and thought that'll solve our issue
> and in a way it does
> but this it doesn't come out to a nice solution because we had to copy and
> slightly change quite a
> lot of your sources.
>
> The expiration policy we want to implement is supposed to ask every client
> via http (this is a protocol extension) about the last access time of the
> calling user. The maximum of the returned times is stored at the
> TicketGrantingTicket which sounds correct to us.
> Therefore we had to subclass TicketGrantingTicketImpl and from that point
> we're introduced to the
> CAS 'final' policy.
> Since many classes are coming down to use not even the interface but
> TicketGrantingTicketImpl we had to copy and slightly change the following
> classes:
>  + AbstractTicket.java
>  + ServiceTicketImpl.java
>  + TicketGrantingTicketImpl.java
>  + HttpClient.java (protocol matters)
>  + CentralAuthenticationServiceImpl.java
>  + SimpleWebApplicationServiceImpl.java
>
> This is quite a list, don't you think.


Actually, considering we designed against this, I'm surprised you didn't
have to modify more ;-)


> So here're the questions:
>  - Is there something wrong trying to solve our issue the way I described?


So you're saying that each ticket periodically polls all services?  Is there
a queue? A threadpool? We don't recommend anything besides CAS and the user
to be able to change any state of  the TicketGrantingTicket.

>
>  - Why do the sources of central classes (AbstractTicket,
> CentralAuthenticationServiceImpl) work
>     with implementation classes (TicketGrantingTicketImpl) and not with
> the related interfaces?


Sometimes, unfortunately, its due to JPA and how it works (and doesn't
work).

>
>  - As far as I understand the sources right now it is not possible to have
> its own TGT implementation
>    without its own CAS implementation and much more. Wouldn't it be better
> to have some kind of a
>    TicketGrantingTicketFactory to solve this issue?


We've considered it but ultimately is was overkill (not that some the other
stuff isn't also).  The number of people who have even thought about
customizing the TGT has been pretty minimal over the past three years.


>  - Can we discuss the final in TicketGrantingTicketImpl under these
> circumstances?


I can't make any guarantees that we'll remove the final, but we're always
willing to work with people to make sure their use case is supported as best
as possible without compromising the system for everyone else.

You should also make sure your use case is detailed here in our roadmap so
we're aware of it for the next version:
 http://www.ja-sig.org/wiki/display/CAS/CAS+Vision+and+Roadmap

Thanks
-Scott


>
> I hope someone reads that and more exiting understands our issue;)
> greetings,
> Ralf
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080611/479788fb/attachment.html