Long Term Authentication / RememberMe vs. Ticket Registry implementations

[Paul Roemer]

Hey guys,

I am debugging the unexpected remember-me behavior of our CAS instance and noticed an issue in the Redis ticket registry implementation with respect to the used expiration timeout.

From RedisTicketRegistry.java:
private static Long getTimeout(final Ticket ticket) {

  val ttl = ticket.getExpirationPolicy().getTimeToLive();

  [...]

}

Because of the way the remember-me expiration policy is implemented, this call will always return the expiration of the DEFAULT expiration policy. Only ExpirationPolicy.getTimeToLive(final TicketState ticketState) will resolve the correct expiration policy (based on if remember-me is active or not) and return the correct expiration timeout.

After understanding the problem, I checked the documentation and noticed:
"The use of long term authentication sessions dramatically increases the length of time ticket-granting tickets are stored in the ticket registry. Loss of a ticket-granting ticket corresponding to a long-term SSO session would require the user to re-authenticate to CAS. A security policy that requires that long term authentication sessions MUST NOT be terminated prior to their natural expiration would mandate a ticket registry component that provides for durable storage, such as the JPA Ticket Registry."

Now I wonder, how a "a ticket registry component that provides for durable storage" is defined. From my opinion Redis would also be a valid option.

Then, I also noticed https://github.com/apereo/cas/pull/3386 which fixes exactly this bug for the MongoDB based ticket registry implementation.

So, now I wonder what to provide.
A) A fix for each ticket registry implementation respecting the remember-me expiration policy?
B) At least a warning during startup in case remember-me is enabled but a non-supported ticket registry is used?

I am happy to help!

Cheers,

  Paul