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

Ralf Lorenz ralf.lorenz at mms-dresden.de
Mon Jun 9 10:36:42 EDT 2008


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?
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.
So here're the questions:
  - Is there something wrong trying to solve our issue the way I described?
  - Why do the sources of central classes (AbstractTicket,  
CentralAuthenticationServiceImpl) work
     with implementation classes (TicketGrantingTicketImpl) and not with  
the related interfaces?
  - 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?
  - Can we discuss the final in TicketGrantingTicketImpl under these  
circumstances?

I hope someone reads that and more exiting understands our issue;)
greetings,
Ralf


More information about the cas-dev mailing list