cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and Memcache ticket experation policy

249 views
Skip to first unread message

John Bond

unread,
Jun 1, 2020, 11:09:55 AM6/1/20
to CAS Community
Hello All,

In out config we set both cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and cas.ticket.tgt.maxTimeToLiveInSeconds to the same value believing theses where the same and  made a note to validate this with this group[1]. That later step never happened and the config remained.  however today i tried to implement memcache as the ticket store and i noticed via tcpdump that CAS was setting the memcache value with an expiry time of -1, this effectively means don't cache so when CAS tries to fetch the ticket it doesn't exist.   Checking my logs i notice the following debug messages which seemed confusing


    2020-06-01 14 05 44,597 DEBUG [org.apereo.cas.ticket.expiration.builder.TicketGrantingTicketExpirationPolicyBuilder] - <Ticket-granting ticket expiration policy is based on a timeout of [604800] seconds>
    2020-06-01 14 05 44,599 DEBUG [org.apereo.cas.ticket.expiration.builder.TicketGrantingTicketExpirationPolicyBuilder] - <Final effective time-to-live of ticket-granting ticket expiration policy is [9223372036854775807] seconds>

memcache only supports an int for the expiry however the final value we have is 9223372036854775807, my assumption is that this at some point this gets coalesced down to -1.  however i'm curious why the final value is not 604800.

Looking at the code i see that when setting  `cas.ticket.tgt.timeout.maxTimeToLiveInSeconds` the final timeout value comes from TimeoutExpirationPolicy.java which always returns Long.MAX_VALUE[1].  When setting only `cas.ticket.tgt.maxTimeToLiveInSeconds`  the timeout value comes from TicketGrantingTicketExpirationPolicy.java which returns `this.maxTimeToLiveInSeconds` which is the value i would expect.  The logic that makes this choice is in TicketGrantingTicketExpirationPolicyBuilder.java

With this in mind could someone explain the difference between the two config items or point me to further documentation.  Further it seems that the use of cas.ticket.tgt.timeout.maxTimeToLiveInSeconds is not currently compatible with memcache.

We are running CAS 6.5.1 on debian buster, let me know if further information is required.

Thanks


[3]https://github.com/apereo/cas/blob/v6.1.5/core/cas-server-core-tickets-api/src/main/java/org/apereo/cas/ticket/expiration/builder/TicketGrantingTicketExpirationPolicyBuilder.java#L70-L73

Ray Bon

unread,
Jun 1, 2020, 12:16:14 PM6/1/20
to cas-...@apereo.org
John,


timeout.maxTimeToLive... is a hard timeout. The other is a 'must be used within this time' to be valid. If the TGT is used within this window, the validity will extend by that time up to timeout.maxTimeToLive...

Ray
--
Ray Bon
Programmer Analyst
Development Services, University Systems

I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations.

John Bond

unread,
Jun 1, 2020, 12:35:51 PM6/1/20
to cas-...@apereo.org
Hi Ray,

Thanks for the response however ...

On Mon, Jun 1, 2020 at 6:16 PM Ray Bon <rb...@uvic.ca> wrote:
John,


timeout.maxTimeToLive... is a hard timeout. The other is a 'must be used within this time' to be valid. If the TGT is used within this window, the validity will extend by that time up to timeout.maxTimeToLive...

I thought that was the difference between cas.ticket.tgt.maxTimeToLiveInSeconds and cas.ticket.tgt.maxTimeToLiveInSeconds i.e.

  * cas.ticket.tgt.timeToKillInSeconds
    - If cas has seen no access from a user in this time kill the ticket
   * cas.ticket.tgt.maxTimeToLiveInSeconds
    - Regardless of anything always kill the ticket after this timeout
  * cas.ticket.tgt.timeout.maxTimeToLiveInSeconds
    - ???

If not what does cas.ticket.tgt.timeToKillInSeconds control?

Thanks

Ray Bon

unread,
Jun 1, 2020, 4:58:58 PM6/1/20
to cas-...@apereo.org
John,

Timeout has higher priority than Default.
timeout.maxTimeToLiveInSeconds is a more general approach (an application like an webmail client, that hits cas every 10m when it checks for new mail, will keep the TGT alive while the tab is open).

The two settings in Default, maxTimeToLiveInSeconds and timeToKillInSeconds, provide for the timeout sliding window but have a hard stop at maxTimeToLiveInSeconds. (With this approach, webmail app will require a new log in after maxTimeToLiveInSeconds.)

In my previous response, I incorrectly stated the behaviour.

says that to disable a policy, set its value to 0 or less.
Maybe by setting timeout.maxTimeToLiveInSeconds, it forces maxTimeToLiveInSeconds to -1 and this value gets sent to memcache.

The similarly named fields are quite confusing (I got caught this morning). Perhaps it would be clearer if timeout.maxTimeToLiveInSeconds and timeToKillInSeconds where named sessionTimeToLiveInSeconds, since they refer to the length of time the session will live after the last time the TGT was used.

Ray

John Bond

unread,
Jun 2, 2020, 6:31:18 AM6/2/20
to cas-...@apereo.org
Hi Ray,

Thanks for the explanation this is very helpful, i'd like to update our documentation[1] and want to ensure i understand this correctly.  Is the following be correct

# Timeout level
If maxTimeToLiveInSeconds is specified at the timeout level as in the following example, then it takes precedence over all other settings and creates a hard expiration policy such that a users session will always be killed after this time is reached

```
cas.ticket.tgt.timeout.maxTimeToLiveInSeconds=86400
```

With this configuration a user will have to re-authenticate after 1 day (86400 seconds)

# Default level
When setting maxTimeToLiveInSeconds and timeToKillInSeconds at the default level as in the following example.  A sliding window is created such that an applications TGT is valid for a week (640800 seconds) as long as some activity occurs every hour (3600 seconds)

```
cas.ticket.tgt.timeToKillInSeconds=3600
cas.ticket.tgt.maxTimeToLiveInSeconds=640800
```

With theses setting a user will be required to re authenticate if either of the following occurs:
  * there has been no activity with CAS within one hour
  * On week after the user authenticated with CAS

# RemberMe
timeToKillInSeconds can also be set at the remberMe level as below.  With this setting a user will be issued with a long term cookie instead of a session cookie.  This long term cookie creates another sliding window where the users can keep the TGT while the long term rememberMe cookie was still valid.  With the following settings and assuming the users ticks Remember Me, a TGT is valid for a week (640800 seconds) as long as some activity occurs every day (86400 seconds).  If the users does not tick Remeber Me the behaviour is the same the above example, setting maxTimeToLiveInSeconds and timeToKillInSeconds at the default level


```
cas.ticket.tgt.timeToKillInSeconds=3600
cas.ticket.tgt.maxTimeToLiveInSeconds=640800
cas.ticket.tgt.rememberMe.enabled=true
cas.ticket.tgt.rememberMe.timeToKillInSeconds=86400
```

With theses setting  and assuming the user checks the remember me box, they will have to reauthenticate if either of the following occurs:
  * there has been no activity with CAS within one day
  * On week after the user authenticated with CAS


>Maybe by setting timeout.maxTimeToLiveInSeconds, it forces maxTimeToLiveInSeconds to -1 and this value gets sent to memcache.

In my initial config i had the following

```
cas.ticket.tgt.timeToKillInSeconds=3600
cas.ticket.tgt.maxTimeToLiveInSeconds=604800
cas.ticket.tgt.timeout.maxTimeToLiveInSeconds=604800
```
Following the code and checking the debug messages i can see that the timeout policy choses is based on `cas.ticket.tgt.timeout.maxTimeToLiveInSeconds` which ultimately uses `org.apereo.cas.ticket.expiration.TimeoutExpirationPolicy` for the expiration policy which returns Long.MAX_VALUE[3] when org.apereo.cas.ticket.registry.MemcachedTicketRegistry set the ticket[4] and calculates the timeout[5].  The timeout is eventually returned with ttl.intValue()[6] and a quick test shows that the following results in ttl value of -1.

  var ttl = Long.valueOf(Long.MAX_VALUE).intValue();

However i am still missing something as Long.MAX_VALUE should have been converted to Long.valueOf(Integer.MAX_VALUE)[7].

Thanks for your help and patience and i think my references are correct this time :)

John


--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to a topic in the Google Groups "CAS Community" group.
To unsubscribe from this topic, visit https://groups.google.com/a/apereo.org/d/topic/cas-user/6g-wrMy75Mw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/4d67023b25aac96a9dd0037adcb133b5e548ae7c.camel%40uvic.ca.

Ray Bon

unread,
Jun 2, 2020, 12:04:01 PM6/2/20
to cas-...@apereo.org
John,

I think timeout.maxTimeToLiveInSeconds provides a sliding window with no defined stop time.

I set our remember me to the same as maxTimeToLiveInSeconds, so do not know if it provides a sliding window.

Ray

On Tue, 2020-06-02 at 12:31 +0200, John Bond wrote:
Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

John Bond

unread,
Jun 3, 2020, 6:48:47 AM6/3/20
to cas-...@apereo.org
Ray

On Tue, Jun 2, 2020 at 6:04 PM Ray Bon <rb...@uvic.ca> wrote:
John,

I think timeout.maxTimeToLiveInSeconds provides a sliding window with no defined stop time.
Ahh thanks, This now makes sense why org.apereo.cas.ticket.expiration.TimeoutExpirationPolicy returns Long.MAX_VALUE for its TTL
 
I set our remember me to the same as maxTimeToLiveInSeconds, so do not know if it provides a sliding window.
Ack thanks very much appreciate the assistance

John

Appify

unread,
Jun 4, 2020, 4:32:30 AM6/4/20
to cas-...@apereo.org
Hello John and Ray,

We are also using memcached as a ticket registry and facing the same issue as the remember me functionality not working properly as expected.  Below is our configuration. Are you doing anything wrong. 
cas.ticket.tgt.rememberMe.enabled=true
cas.ticket.tgt.rememberMe.timeToKillInSeconds=2592000
cas.ticket.tgt.maxTimeToLiveInSeconds=2592000
cas.ticket.tgt.timeToKillInSeconds=2592000

# cas.tgc.path=/
# cas.tgc.maxAge=-1 If one modified this to an positive number,
# you will get the behavior of CAS session after browser close and re-open.
cas.tgc.maxAge=-1
cas.tgc.name=TGC
cas.tgc.secure=true
# cas.tgc.httpOnly=true
cas.tgc.rememberMeMaxAge=2592000
cas.tgc.pinToSession=true Thanks in advance.

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
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 view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAA7%2BHnD3bmq%2BQe%2BRKCPs63FV4%2BVw-iyWk%2Btdxs502En8saRpQQ%40mail.gmail.com.


--
-Fazla.

John Bond

unread,
Jun 4, 2020, 5:31:51 AM6/4/20
to CAS Community

Hi Fazla,

We use are now using the following settings

cas.ticket.tgt.rememberMe.enabled=true
cas.ticket.tgt.rememberMe.timeToKillInSeconds=604800
cas.ticket.tgt.timeToKillInSeconds=3600
cas.ticket.tgt.maxTimeToLiveInSeconds=604800

We are still testing but the intention is that someone who sets RemeberMe will get a long term cookie and not need to re-authenticate for one week.  however if you don't set remember me i.e. in public place or shared cookie, then your session will be killed after an hour of inactivity.  this allows us to clean up dead sessions quickly in-case users forget to log out.  We have not changed any of the values at the `cas.tgc` level, other then the encryption and signing keys, as such we will be using what ever the defaults are,.

Thanks John
To unsubscribe from this group and stop receiving emails from it, send an email to cas-...@apereo.org.


--
-Fazla.

Appify

unread,
Jun 4, 2020, 11:29:31 AM6/4/20
to cas-...@apereo.org
Hi John,

Thanks for your reply. I saw your configuration and I will try this in our staging environment. I was wondering about cas.tgc.rememberMeMaxAge properties, what does that do? Also if this config works for you please let me know.

Thanks. Regards

To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/7ab8147d-0661-41d2-9a52-a7e6a1ac7aac%40apereo.org.

John Bond

unread,
Jun 4, 2020, 12:40:24 PM6/4/20
to cas-...@apereo.org

Hi Fazla,

Unfortunately i'm unsure what cas.tgc.rememberMeMaxAge is used for and how it differes from cas.ticket.tgt.rememberMe.timeToKillInSeconds=

Ray Bon

unread,
Jun 4, 2020, 1:12:53 PM6/4/20
to cas-...@apereo.org
Fazla,

This is what I have in my config
## default is P14D
## used to set maxAge on user selection of remember me at login
## it is always set regardless of user choice; this is a bug to investigate
cas.tgc.rememberMeMaxAge=-1

I am not sure how it affects users but we limit max log in to 8h.

Ray
Reply all
Reply to author
Forward
0 new messages