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 <ray.wal...@nau.edu>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 > > <ray.wal...@nau.edu> 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" <scott.battag...@gmail.com> > > 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 <ray.wal...@nau.edu > > > 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 > > >> ray.wal...@nau.edu > > >> Phone 928-523-0334 > > >> > > >> > > >> > > >> -- > > >> You are currently subscribed to cas-dev@lists.jasig.org as: > > >> scott.battag...@gmail.com > > >> To unsubscribe, change settings or access archives, see > > >> http://www.ja-sig.org/wiki/display/JSG/cas-dev > > >> > > > > > > -- > > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > > > > -- > > You are currently subscribed to cas-dev@lists.jasig.org as: > ray.wal...@nau.edu > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
