A more strategic question: are there use cases for separating PGT expiration policy from TGT expiration policy? Might a CAS adopter reasonably want single sign-on sessions that are longer in duration than the proxying sessions of applications users log into? I suspect yes, that I might well want to put a tighter hard timeout on an application's ability to proxy on my behalf than on the single sign-on TGT token in my browser.
Indeed, for CAS adopters using PGTs only for ClearPass password replay integrations, PGTs need be valid for only an eyeblink, and there's some advantage to expiring them out as soon as possible rather than leaving active a PGT capable of getting a PT capable of retrieving the end user's password. In the use cases that I am aware of, the PGT is used in the following way: The user logs into web application (via CAS) and then makes some requests via the web UI. The web application needs to make further RESTful calls on the user's behalf to CAS protected REST endpoints. In this case, you want the PGT to last as long as the session the application is valid; otherwise in the middle of the user's application session, the PGT becomes invalid and the backend can't make more PT's and may get stuck. There are actually 3 different timeouts involved here: TGT, PGT and application session (out of the control of CAS). I'm actually in the middle some internal discussions on how to properly set the timeouts policies in this situation. It is possible that if the PGT times out, we would just try to kick the user back to CAS to get a new ST, but this could lose the application state, so if we can do better with a proper setting of policies, it would be better. We are just starting to really think through the possibilties in earnest, so I'll post back with further thoughts if we have any... Given that, would it make sense for CAS to out-of-the-box tease this apart, providing a plugin/configuration point for TGT expiration, for ST expiration, and for PGT expiration, explicitly; that is, 3, rather than 2, expiration policy entries in the relevant XML configuration file and in cas.properties? I do expect the TGT expiration policy could be coded to differentiate and apply differential policies to TGTs vs PGTs, but that's sounding like a complex, custom solution to what might be configuration that could be expressed more simply by exposing more of the conceptual domain (TGTs, STs, PGTs) in ticket expiration configuration. Kind regards, Andrew On Wed, Nov 21, 2012 at 6:58 PM, Ohsie, David <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]>] Sent: Wednesday, November 21, 2012 4:44 PM To: [email protected]<mailto:[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]<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
