Hi, We just found this: https://github.com/apereo/cas/pull/3221
It looks like it is a known issue and it will (hopefully) get solved in the next release :) Jon On Thursday, March 15, 2018 at 8:00:02 PM UTC+1, Jon wrote: > > 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 | [email protected] >>> >>> -- - 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/80f8b855-ce53-458a-8395-72d584896cf4%40apereo.org.
