Re: [cas-user] Preventing removal of OAuth tokens upon TGT expiration for one service

[Yan Zhou]

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
On Thursday, March 15, 2018 at 3:48:01 PM UTC-4 Jon wrote:

> 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 
>>> .
>>>  
>>> 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 

Re: [cas-user] Preventing removal of OAuth tokens upon TGT expiration for one service

[Jon]

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 
> .
>  
> 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: 

Re: [cas-user] Preventing removal of OAuth tokens upon TGT expiration for one service

['Caleb D' via 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


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

Re: [cas-user] Preventing removal of OAuth tokens upon TGT expiration for one service

[Ray Bon]

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 | r...@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/1506379117.1759.10.camel%40uvic.ca.