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. 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<mailto: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<mailto: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<mailto: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<mailto: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>. -- Ray Bon Programmer Analyst Development Services, University Systems 2507218831 | CLE 019 | r...@uvic.ca<mailto: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 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/cb28e25f6e21478eb25f9e002cc774f7db606332.camel%40uvic.ca.
