Preventing removal of OAuth tokens upon TGT expiration for one service

434 views
Skip to first unread message

Caleb D

unread,
Sep 25, 2017, 6:15:19 PM9/25/17
to CAS Community
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

unread,
Sep 25, 2017, 6:38:41 PM9/25/17
to cas-...@apereo.org
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
-- 
Ray Bon
Programmer analyst
Development Services, University Systems
2507218831 | CLE 019 | rb...@uvic.ca

Caleb D

unread,
Sep 25, 2017, 7:25:04 PM9/25/17
to CAS Community
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. 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

Jon

unread,
Mar 15, 2018, 3:00:02 PM3/15/18
to CAS Community
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

Jon

unread,
Mar 15, 2018, 3:48:01 PM3/15/18
to CAS Community
Hi,


It looks like it is a known issue and it will (hopefully) get solved in the next release :)

Jon

Yan Zhou

unread,
Mar 8, 2023, 2:57:18 PM3/8/23
to CAS Community, Jon
Hi, 

We are using CAS 6.4.6.6, I still find this is the case,   RT is removed (We like it to expire in 7 days), but it was removed after 8 hours, because the underlying TGT expired, which is default to 8 hours.

i did not understand why Logout behavior would affect RT retention when TGT is removed. I did not logout, 

I tried to set TGT expiration policy under this particular service to a much bigger value in JSON service registry, but run into Nullpointer exception error in CAS in code below, part of DefaultSingleSignOnParticipationStrategy.

            val tgtPolicy = registeredService.getTicketGrantingTicketExpirationPolicy();
            if (tgtPolicy != null) {
                val ticketState = getTicketState(ssoRequest);    <==  ticketState is Null
                return tgtPolicy.toExpirationPolicy()
                    .map(policy -> !policy.isExpired(ticketState.get())).orElse(Boolean.TRUE);
            }

Is this fixed in CAS 6.4.6.6?

Thanks,
Yan
Reply all
Reply to author
Forward
0 new messages