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
>>> <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 Systems2507218831 <(250)%20721-8831> |
>>>> 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/6fca34af-10fa-4cf6-bae4-2207bbedc767n%40apereo.org.
