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 <javascript:> > > -- - 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/6d00767c-c328-47de-a8dd-5e4b9da33f13%40apereo.org.
