Hi, We are running into the same issue you had. This is how we set our expiration properties:
cas.ticket.tgt.timeToKillInSeconds=7200 cas.ticket.tgt.maxTimeToLiveInSeconds=28800 cas.authn.oauth.refreshToken.timeToKillInSeconds=604800 cas.authn.oauth.accessToken.timeToKillInSeconds=86400 cas.authn.oauth.accessToken.maxTimeToLiveInSeconds=86400 We tried setting the "cas.logout.removeDescendantTickets" property to false but this only prevents the TGT ticket from being deleted. However, if the TGT ticket has expired (because of the TGT max life setting), both the access token and refresh token are invalid. If we try to use the refresh token to generate a new access token, we get an "invalid_request" error. Did you figure out how to solve it? Thanks in advance, Jon On Tuesday, September 26, 2017 at 1:25:04 AM UTC+2, Caleb D wrote: > > Hey Ray, thanks for responding. > > Yes, the application frequently uses the OAuth access token and refresh > token given to it after the user authenticates. During each application > invocation, the application uses the access token it was given as > authentication in some web service calls. If the access token is expired, > it uses the refresh token to obtain a new access token (this is typical > behavior in OAuth 2). However, if the refresh token is invalid (e.g. due to > expired TGT), the application interaction is halted. The UX for this > scenario is poor and this behavior is outside our control. This is for some > hands free voice integration work, so even if we could somehow reprompt for > authentication the user wouldn't be in a good position to provide > credentials (or might not be able to because the hardware was configured by > someone else). > > That leads us to a solution of keeping refresh tokens alive for a long > time, but we don't want to increase the TGT max life because that would > affect other services as well and feels too broad with unknown implications. > > We've set logoutType to NONE on the service definition for this > application, but this only disables CAS' behavior of POSTing to a logout > endpoint for the application. It doesn't change the behavior of expiring > OAuth refresh tokens when the parent TGT expires. It looks like the way to > change that behavior is to override the logoutExecutionPlan bean or to > define our own LogoutManager and I was hoping to find or hear of an > example of doing such. > > The problematic code we want to work around can be seen in the CAS source, > the method CasCoreLogoutConfiguration::configureLogoutExecutionPlan > <https://github.com/apereo/cas/blob/5.1.x/core/cas-server-core-logout/src/main/java/org/apereo/cas/logout/config/CasCoreLogoutConfiguration.java#L108>. > > When a TGT is expired, all descendant tickets are also deleted. The default > logoutExecutionPlan bean configures the behavior, so hence my questions > regarding overriding it. > > Thanks, > Caleb > > > On Monday, September 25, 2017 at 6:38:41 PM UTC-4, rbon wrote: >> >> Caleb, >> >> You can turn off single logout for that application (more accurately, not >> turn it on). >> Or are you saying that this application periodically probes CAS to check >> for a valid login? >> >> Ray >> >> On Mon, 2017-09-25 at 15:15 -0700, 'Caleb D' via CAS Community wrote: >> >> Hello, >> >> We're trying to implement a special case behavior in CAS 5 concerning >> OAuth. When a user authenticates, a TGT, refresh token, and access token >> are generated. By default when the TGT expires, the refresh token and >> access token are also removed (lambda defined by >> CasCoreLogoutConfiguration::configureLogoutExecutionPlan). We'd like to >> special case one of our services and change this behavior so that when a >> TGT expires the refresh token and access token remain. This is because our >> service expects a very long lifetime for the refresh token and currently >> doesn't reprompt for authentication if the refresh token is invalid. We >> don't want to increase the lifetime of all TGTs (via >> cas.ticket.tgt.timeout.maxTimeToLiveInSeconds) because that would affect >> other services and is too broad. >> >> Is there a recommended approach for implementing this behavior? It looks >> like overriding the logoutExecutionPlan bean is one potential approach. >> Has anyone tried overriding logoutExecutionPlan or DefaultLogoutManager? >> >> Or, if there is another approach that better fits what we're trying to >> achieve, please do share. We aren't concerned with the SSO aspect of CAS >> for this particular service, we just want a long lasting refresh token that >> isn't governed by a parent TGT. >> >> Interested in any direction or help the community can provide. >> >> Thanks, >> Caleb >> >> -- >> Ray Bon >> Programmer analyst >> Development Services, University Systems >> 2507218831 | CLE 019 | rb...@uvic.ca >> >> -- - 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/2832f53c-ac55-44f2-a38a-afa72aa5c670%40apereo.org.
