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]> 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]> 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] as:
> [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****
>
> --
> 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
>
>
--
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
