This makes sense and is valid for determining the end of life of a service ticket. What I'm noticing that I've failed to mention, is that when also dealing with proxies, the process of acquiring a user's authentication expiration time becomes a bit more convoluted. The reason for this is to determine how long a proxy would be able to successfully grant tickets for it's applications.
Modifying my previous example, when we login & validate serviceA, then move on to proxy serviceZ, the TGT retrieved for proxy is at first good until 2hrs from serviceA's validation (approxmately.)
But if we then validate serviceB (and/or other services) one hour later, this effectively extends the time that the user is authenticated one hour past the end of service A's validation.
If I understand correctly, this would effectively extend the usefulness of serviceZ's TGT by one hour. With this in mind, we also know that serviceA & serviceB have no interaction, therefore when serviceZ proxyValidates, there would not be a proper way to obtain a correct time of how long the user would be authenticated for.
(Another potential scenario is if the root TGT's expiration time was less than that of the proxy's TGT. I'm not sure if that is even possible?)
I see that the under .isExpired within AbstractTicket.java the TGT chain is followed to it's root. The root TGT's last used time is updated when /cas/login is called for a service. I believe that this is the time we'd like to acquire, which could be done in a method similar in fashion to how .isExpired tunnels down the TGT chain.
We're looking into the addition of an optional parameter to retrieve this time, at one of two points, either in the cas/proxy or cas/proxyValidate
My question is, is there another preferred method or point of entry to do something like this?
> Wouldn't you just be able to do "new Date()" in the JSP page to get the current time the ticket was validated (which is probably within 10 seconds of when it was issued) and then add 2 hours to that?
>
>
> On Tue, Nov 10, 2009 at 1:38 PM, Raymond D Walker <
[hidden email]> wrote:
> Scott,
>
> In reviewing this, I do not believe we can get a valid expiration time
> for the user's authentication via the suggested method. I also believe
> the title might now be considered misleading as we're looking for a
> user's credential expiration time, not necessarily a ticket expiration
> time.
>
> In our setup we are using the default ticket expiration policy (2hr).
>
> In modifying the casServiceValidation.jsp to extract the Dates from
> the Authentication list, also have exposed the "root" which contains
> the initial Authentication time for the user. This time seems to never
> change.
>
> For example:
>
> 3:00pm
> cas/login?service=serviceA
>
> On validation, this gives us an Authentication List with the root
> authentication time of 3:00pm. The idea is to do math on this time
> (user valid till 5pm,) which makes sense.
>
> 4:00pm
> cas/login?service=serviceB
>
> On validation, this gives us an Authentication List with the root
> authentication time of 3:00pm (with no other nodes.) We would not be
> able to correctly do math on this time, since they're valid till
> 6:00pm and are able to login to new and existing services without re-
> authenticaiton until 6:00pm.
>
> In reviewing the other ticket expiration policies, I do not see a
> policy which would modify this time. I'm curious if we're just looking
> in the wrong direction to acquire a user's expiration time. Any ideas?
>
> Raymond Walker
> Software Systems Engineer Sr.
> ITS Northern Arizona University
>
> On Jul 7, 2009, at 7:26 PM, Scott Battaglia wrote:
>
> > Raymond,
> >
> > To our JSP that generates the CAS response, we expose an Assertion
> > object:
> >
https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/validation/Assertion.java> >
> > While it doesn't have the expiration times explicitly, it does have
> > the authentication objects which contain the time when they were
> > created:
> >
https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/authentication/Authentication.java> >
> > which could allow you to construct your expiration time.
> >
> > The only thing you'd modify is the JSP page.
> >
> > Cheers,
> > Scott
> >
> > -Scott Battaglia
> > PGP Public Key Id: 0x383733AA
> > LinkedIn:
http://www.linkedin.com/in/scottbattaglia> >
> >
> > On Mon, Jul 6, 2009 at 11:35 AM, Raymond D Walker
> > <
[hidden email]> wrote:
> > Scott,
> >
> > Apologies, I was unclear with this. Essentially our modification
> > found the
> > expiration of the beginning of the ticket chain.
> >
> >
> > On 7/6/09 8:26 AM, "Scott Battaglia" <
[hidden email]>
> > wrote:
> >
> > > Can you clarify what you mean by "CAS credentials" because in your
> > title you
> > > talk about returning ticket expiration time (TGT, ST, PT, etc?)
> > >
> > >
> > > On Mon, Jul 6, 2009 at 11:20 AM, Raymond D Walker <
[hidden email]
> > > wrote:
> > >> Howdy folks,
> > >>
> > >> In researching for our upgrade to CAS 3.x I'm looking to put some
> > backwards
> > >> compatibility into our implementation for some custom
> > modifications made in
> > >> our CAS2.x implementation.
> > >>
> > >> For a few particular applications, we added an optional parameter
> > into
> > >> serviceValidate and proxyValidate that allowed for the return of
> > the
> > >> expiration time of the cas credentials. This modification was
> > somewhat
> > >> involved and required a large amount of class modification.
> > >>
> > >> For our CAS3.x rollout, we'd like to stay away from major
> > modifications such
> > >> as this, but I wanted to bounce the idea off the list to see if
> > there was
> > >> any straightforward methods to do something similar. Peeking into
> > the code,
> > >> and being only mildly familiar with Spring, I'm not seeing this
> > as of yet.
> > >> It's looking like a large amount of class modification. Not
> > implementing
> > >> this mod will push back our upgrade till some other systems are
> > dealt with,
> > >> which is not the issue, but I would like to see what the dev list
> > has to say
> > >> about this type of modification, or if anyone has implemented
> > something
> > >> similar.
> > >>
> > >> Thanks much,
> > >> --
> > >> Raymond Walker
> > >> Software Systems Engineer Sr.
> > >> ITS Northern Arizona University
> > >>
[hidden email]
> > >> Phone 928-523-0334
> > >>
> > >>
> > >>
> > >> --
> > >> You are currently subscribed to
[hidden email] as:
> > >>
[hidden email]
> > >> To unsubscribe, change settings or access archives, see
> > >>
http://www.ja-sig.org/wiki/display/JSG/cas-dev> > >>
> >
> >
> > --
> > You are currently subscribed to
[hidden email] as:
[hidden email]
> > To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev> >
> >
> > --
> > You are currently subscribed to
[hidden email] as:
[hidden email]
> > To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev>
>
> --
> You are currently subscribed to
[hidden email] as:
[hidden email]
> To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev>
>
> --
> You are currently subscribed to
[hidden email] as:
[hidden email]
> To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev