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 [1] https://wikitech.wikimedia.org/wiki/CAS-SSO/Administration#Session_timeout_handling [2] 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 [3] https://github.com/apereo/cas/blob/v6.1.5/core/cas-server-core-tickets-api/src/main/java/org/apereo/cas/ticket/expiration/TimeoutExpirationPolicy.java#L74 [4] https://github.com/apereo/cas/blob/master/support/cas-server-support-memcached-ticket-registry/src/main/java/org/apereo/cas/ticket/registry/MemcachedTicketRegistry.java#L59 [5] https://github.com/apereo/cas/blob/master/support/cas-server-support-memcached-ticket-registry/src/main/java/org/apereo/cas/ticket/registry/MemcachedTicketRegistry.java#L128 [6] https://github.com/apereo/cas/blob/master/support/cas-server-support-memcached-ticket-registry/src/main/java/org/apereo/cas/ticket/registry/MemcachedTicketRegistry.java#L138 [7] https://github.com/apereo/cas/blob/master/support/cas-server-support-memcached-ticket-registry/src/main/java/org/apereo/cas/ticket/registry/MemcachedTicketRegistry.java#L130 On Mon, Jun 1, 2020 at 10:59 PM Ray Bon <r...@uvic.ca> wrote: > 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. > > > https://apereo.github.io/cas/6.1.x/configuration/Configuration-Properties.html#tgt-expiration-policy > 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 > > On Mon, 2020-06-01 at 18:35 +0200, John Bond wrote: > > Hi Ray, > > Thanks for the response however ... > > On Mon, Jun 1, 2020 at 6:16 PM Ray Bon <r...@uvic.ca> wrote: > > John, > > > https://apereo.github.io/cas/6.1.x/ticketing/Configuring-Ticket-Expiration-Policy.html > > 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... > View Task <https://phabricator.wikimedia.org/T245771> > > > 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 > Programmer Analyst > Development Services, University Systems > 2507218831 | CLE 019 | r...@uvic.ca > > 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. > > -- > - 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+unsubscr...@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 > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/4d67023b25aac96a9dd0037adcb133b5e548ae7c.camel%40uvic.ca?utm_medium=email&utm_source=footer> > . > -- - 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+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAA7%2BHnAW_jQY0SXv9OzHocmtbGXOv1KMAYR6148f39AL8rEWcg%40mail.gmail.com.
