CAS v5 handles this sort of thing automatically. It can be that simple. Depends. 5 allows you to separate the policy between a TGT and PGP. So it’s more flexible in that regard. If you wish to not go that extra mile, then sure. What you have seems sufficient, but that is the limitation.
Since you’re prototyping, I strongly recommend that you start with 5 to get that behavior for free. (Changing the internals of AbstractTicket could result into severe consequences maintenance-wise) From: [email protected] [mailto:[email protected]] On Behalf Of Pierre Hantz Sent: Wednesday, April 27, 2016 7:08 AM To: CAS Developer <[email protected]> Subject: [cas-dev] A very simple solution (?) for PGT to survive TGT inactivity expiration Hi, We are prototyping a SSO solution with CAS for some front-end applications that need to connect to back-end services on behalf of the user. Usage of CAS PGT+PT appeared to be a very promising solution. However we are facing a problem that seems to be already known: When the TGT expires because the user has not started new applications, all its child PGT expire as well, even if PGT are actively used. This may be a valid behavior for some other CAS users, but in our case, its means that while the user has still valid sessions on front-end applications, they would sometime fail to get new PT when needed. We would have to force users to stop/restart their application sessions to recover from the situation. This is definitely not an acceptable solution for us (beyond simple web pages, we have also complex client/server applications including heavy Java Web Start GUI clients launched from the browser ...). Once they have authenticated a user using CAS protocol, we want our applications to manage the local user session independently from the session on the CAS server (meaning for example that we would not use CAS SLO). In mail archives there are some discussions proposing to solve unexpected invalidation of PGT by keeping TGT alive (either by applications via the browser or by CAS server when PGT are used), but this is not what we want either. We do want CAS to continue to invalidate TGT not used for SSO. Users must have to explicitly re-authenticate if they want to create a new application session after their session on the SSO server has been invalidated for inactivity, even if they still have valid sessions running on some other applications. I have quickly looked at classes in the org.jasig.cas.ticket package of CAS 4.2.1 and I have commented out the line verifying whether parent ticket has expired or not in the method isExpired() of the class org.jasig.cas.ticket.AbstractTicket. With this modification, as far as we can see with basic tests, we observe exactly the expected behavior: PGT are not invalidated when TGT expires. PGT expire only when they are not used (and it is acceptable for us that an application periodically requests a PT even if not needed, just to keep a PGT alive as long as the user session on the application is valid). @Override public final boolean isExpired() { final TicketGrantingTicket tgt = getGrantingTicket(); return this.expirationPolicy.isExpired(this) /* || (tgt != null && tgt.isExpired()) */ || isExpiredInternal(); } Is it really that simple ? Thanks, Pierre -- You received this message because you are subscribed to the Google Groups "CAS Developer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/. -- You received this message because you are subscribed to the Google Groups "CAS Developer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.
