4.2.x Ticket timeout policies

[Tom Poage]

Afternoon,

Puzzling over documentation on hard timeouts:

https://jasig.github.io/cas/4.2.x/installation/Configuring-Ticket-Expiration-Policy.html

Says for HardTimeoutExpirationPolicy to configure:

<alias name="ticketGrantingTicketExpirationPolicy"
alias="grantingTicketExpirationPolicy" />

with:

> # tgt.timeout.hard.maxTimeToLiveInSeconds

But the only use of this property is in:

ticket/support/HardTimeoutExpirationPolicy.java with a component name of
hardTimeoutExpirationPolicy.

Should documentation for the hard timeout policy show this?

<alias name="hardTimeoutExpirationPolicy"
alias="grantingTicketExpirationPolicy" />

Or is this policy deprecated? I ask, because we're planning to use
Hazelcast, and

ticket/registry/config/HazelcastProperties.java says:

> /**
> * Max idle seconds.
> */
> @Value("${tgt.maxTimeToLiveInSeconds:28800}")
> private int maxIdleSeconds;

and ticket/registry/HazelcastTicketRegistry.java says:

> @Autowired
> public HazelcastTicketRegistry( ...
> @Value("${tgt.maxTimeToLiveInSeconds:28800}")
> final long ticketGrantingTicketTimeoutInSeconds,
> @Value("${st.timeToKillInSeconds:10}")
> final long serviceTicketTimeoutInSeconds) {

i.e it seems tgt.timeout.hard.maxTimeToLiveInSeconds is not used in the
Hazelcast config.

Further, the comment "Max idle seconds" in HazelcastProperties.java
above seems to contradict comments and code in

ticket/support/TicketGrantingTicketExpirationPolicy.java

> @Override
> public boolean isExpired(final TicketState ticketState) {
> final long currentSystemTimeInMillis = System.currentTimeMillis();
>
> // Ticket has been used, check maxTimeToLive (hard window)
> if ((currentSystemTimeInMillis - ticketState.getCreationTime() >= maxTimeToLiveInMilliSeconds)) {
> LOGGER.debug("Ticket is expired because the time since creation is greater than maxTimeToLiveInMilliSeconds");
> return true;
> }
>
> // Ticket is within hard window, check timeToKill (sliding window)
> if ((currentSystemTimeInMillis - ticketState.getLastTimeUsed() >= timeToKillInMilliSeconds)) {
> LOGGER.debug("Ticket is expired because the time since last use is greater than timeToKillInMilliseconds");
> return true;
> }

So the idle timeout is timeToKill and the hard window is timeToLive.
Yes? (I'm starting to find the terminology confusing)

Anyhow, given the TicketGrantingTicketExpirationPolicy.java code, in
order to use a hard timeout, but skip (not use) the idle time out, it
seems I need to set both values to the same i.e.

tgt.maxTimeToLiveInSeconds=NNNNN
tgt.timeToKillInSeconds=NNNNN

FWIW, setting the idle timeout to 0 in 3.5.x (Ehcache) disabled the idle
timeout, leaving only the hard timeout.

Thank you for any clarification!

Tom.

[Misagh Moayyed]

Typo in the docs. Sorry. Fixed it.

The expiration policy config and timeout, as you discovered, is hardcoded
into HZ for 4.2 which assumes a specific expiration policy in use, that is
the default. If you wish to let the default behave like the hard timeout
expiration policy, as you noted and for now, you'll need to "null" out the
idle timeout by effectively using the same values for both settings, that is
idle and max time.

One way to improve this in the future is the following strategy instead:

1. Remove ticket timeout configuration from the registry itself
2. Use the timeouts associated with the expiration policy associated with a
given ticket to store items into a given registry cache, such as HZ.

Every ticket in CAS at construction time has an expiration policy. It makes
sense that registries use the same configuration when storing items. This
allows you to use any kind of policy CAS offers, and the appropriate
registry would then simply ask for "ticket -> expiration policy -> timeout"
when storing the ticket into its own config.

This implies that registries need to be smarter implementation wise, because
not all have idle time outs, some have multiple forms of timeouts and not
all use the same unit of measure when understanding such timeouts! But all
those should be hidden from your POV in the future as the expectation should
be that the registry knows what it's doing, will do all the necessary
translations in between from CAS over to the registry type and you shouldn’t
have to bother/understand all those gory details :)

HTH.

> --
> You received this message because you are subscribed to the Google Groups
> "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-user+u...@apereo.org.
> To post to this group, send email to cas-...@apereo.org.
> Visit this group at
> https://groups.google.com/a/apereo.org/group/cas-user/.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-
> user/572D12A4.8000003%40ucdavis.edu.
> For more options, visit https://groups.google.com/a/apereo.org/d/optout.