An iteresting approach might then be to avoid directly expiring PGT's and let them completely rely on parent TGT expiration (I think that is one of your possibilities below).
Is there a way to actually create a PGT expiration policy that differs from the TGT expiration policyt? Since TicketState doesn't seem to offer the information about a ticket being a PGT, I would imagine that you have to create a "AuthenticationMetaDataPopulator" similar to the " RememberMeAuthenticationMetaDataPopulator" to indicate in the Authentication that this is a PGT and have the expiration policy look at that flag. Or maybe there is an easier way... From: Andrew Petro [mailto:[email protected]] Sent: Wednesday, November 21, 2012 4:44 PM To: [email protected] Subject: Re: [cas-user] Proxy Ticket expiration while session still active A ticket that is a child of an invalid TGT is invalid. CAS climbs the ticket chain to verify that it's valid all the way up. In AbstractTicket [1] the isExpired() method will only consider a ticket un-expired if the granting ticket (if present) is unexpired. public final boolean isExpired() { return this.expirationPolicy.isExpired(this) || (getGrantingTicket() != null && getGrantingTicket().isExpired()) || isExpiredInternal(); } [1]: https://github.com/Jasig/cas/blob/v3.5.1/cas-server-core/src/main/java/org/jasig/cas/ticket/AbstractTicket.java Andrew On Wed, Nov 21, 2012 at 4:23 PM, Ohsie, David <[email protected]<mailto:[email protected]>> wrote: Your CAS server is configured so that PGTs have an idle timeout. Maybe that timeout is too short, or maybe you'd rather they had only a hard timeout. Or maybe you'd rather they had no timeout at all and expired only when the end user's CAS single sign-on session ends. Question: If a PGT has not timed out, but the original TGT used to generate that PGT has timed out, will the PGT still be usable? But if your CAS server configuration accurately reflects your desired policy, that idle PGTs after some amount of time become invalid, then either expiring the PGT is the right outcome and the knob to turn is to hone the experience in your CAS-using application (say, logging in again via CAS is undertaken within the active session rather than creating a new session, an attractive lightbox experience advising the user that their CAS proxying session expired and that they need to re-authenticate. And if you don't desire this particular application's PGTs to expire after the idle timeout while the application is actively used, but want to retain that idle timeout in general, then your solution of artificially making the PGT seem actively used while the end user session persists sounds like a decent solution to keeping that policy in the CAS server yet getting the desired behavior in this application. Andrew On Wed, Nov 21, 2012 at 10:01 AM, <[email protected]<mailto:[email protected]>> wrote: Hi, I'm facing an odd problem. A user connects to an app, by using a ST. The app asks for a PGT. Until now, no problem. The user do his stuff in the app, sometimes calling casified-webservice, thus asking CAS for a PT. Sometimes the user doesn't use the webservice during, for example 2 hours (TGT/PGT default expiration time), but still use actively the app. When 3 hours later (for example) the app asks for a PT for the webservice, the PGT is expired, and the user MUST be disconnected to get another valid PGT. It's a bit awkward having to disconnect the user while the user have been active during all this time. Is there any solution ? How to "synchronize" use of the app (the user session) and PGT expiration. For now, we made a quick and dirty thing : a periodic call to CAS for PT, without using it, just to keep the PGT alive :-/ Any ideas ? Thanks -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
