[cas-dev] expiration policy using the global last access time and the CAS 'final' policy
Ralf Lorenz
ralf.lorenz at mms-dresden.de
Thu Jun 19 09:34:47 EDT 2008
Am 12.06.2008, 18:00 Uhr, schrieb <cas-dev-request at tp.its.yale.edu>:
> Date: Wed, 11 Jun 2008 15:16:05 -0400
> From: "Scott Battaglia" <scott.battaglia at gmail.com>
> Subject: Re: [cas-dev] expiration policy using the global last access
> time and the CAS 'final' policy
> To: "Mailing list for CAS developers" <cas-dev at tp.its.yale.edu>
> Message-ID:
> <1bbd36a10806111216n7984b561o165ef4170180fcb3 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 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).
>
I do not understand that by design argument. By design CAS provides an
interface
called ExpirationPolicy that anyone can implement as desired.
By protocol which I understand to be part of the design as well anyone
first of all
an individual application, e.g. a cas client, can expire the global
session. Thus an
individual application can easily can easily perform a global logout
when its session gets timed out using the CAS protocol. That would be a
real impact of
session timeouts of an individual application (client) using a legal way.
Maybe I didn't describe our issue not in an understandable way.
We only want to implement an ExpirationPolicy that uses HTTP(S) to ask
every known
service to return the time of the last access of the related user to that
individual application.
Furthermore we want to store the maximum of the returned values to the TGT.
CAS is of full control over the complete expiration process. No doubt
about that.
So again and I hope you stick with me in the discussion:
Why is it wrong to implement a policy that ask all clients what the time
of the
last user access was and uses this information to decide whether or not to
expire
the ticket? There's no impact of a clients session which is timing out and
CAS is
the acting part anyway so CAS is of full control.
What do you mean by we designed against this? Are there any rules saying
CAS
uses only this or that ticket implementation? What about rules for
policies?
>>
>> 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
>
see comments above but it sounds weird to work with interfaces and
afterwards close
up the system, don't you think?
>> 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.
>
With the ExpirationPolicy we discuss here CAS would change the state and
no one
else. To decide whether to change state it asks the services. That's all.
If we could
save the maximum time at the ticket the policy wouldn't need to ask the
service everytime
someone calls isExpired() but only if this maximum time is in the past.
>>
>> - 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).
>
I don't understand that.
>>
>> - 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.
>
A key/value map at the TGT would help us out. What about that?
>> - 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-0001.html
> ------------------------------
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
--
T-Systems Multimedia Solutions GmbH
Ralf Lorenz
SoftwareEntwicklung
eHR Solutions
Hausanschrift: Riesaer Strasse 5, 01129 Dresden
Goslarer Ufer 35, 10589 Berlin
Postanschrift: Postfach 10 02 24, 01072 Dresden
Telefon: +49 30 3497-1920
Fax: +49 30 3497-1901
Email: Ralf.Lorenz at mms-dresden.de
Internet: http://www.t-systems-mms.com
Geschäftsführung: Peter Klingenburg, Dr. Jens Nebendahl
Handelsregister: Amtsgericht Dresden (HRB 11433), Sitz der Gesellschaft
Dresden
Ust-IdNr.: DE 811 807 949
++++++++++++++++++++
Leidenschaft. Innovation. Erfolg. Infos unter http://www.t-systems-mms.com
++++++++++++++++++++
More information about the cas-dev
mailing list