Per Service Ticket Expiration in 5.2.x?

[Bill Scully]

Hi,

Does anyone know if the "The expiration policy of ticket granting tickets can be conditionally decided on a per-application basis" in 5.2.x?

I see that is available in 6.3.x:

https://apereo.github.io/cas/6.3.x/ticketing/Configuring-Ticket-Expiration-Policy.html#per-service

and I am specifically interested in increasing the ticket expiration for a given service, not the default:

"org.apereo.cas.services.DefaultRegisteredServiceTicketGrantingTicketExpirationPolicy", "maxTimeToLiveInSeconds": 5

If not, is there a potential workaround where I could extend the life of a ticket to 8 hours for a registered service?

Thanks for your time!

Bill

[Misagh Moayyed]

There exists no such thing. What do you ultimately wish to accomplish with this setting?  

Often what you really should be doing is modifying the application itself to manage its own session for 8 hours.  CAS is not a session manager, and generally has no say when it comes to the application session. 

[Bill Scully]

Thank you for replying, Misagh,

Instructure's Canvas (LMS) oddly links session timeouts to CAS' Ticket Expiration Policy.  So, as I understand it, with the default Ticket Expiration Policy of 2 hours, Canvas sessions are automatically logging out users because Instructure chose to tie their Canvas-user session limits to CAS tickets.  I had to increase the value in cas.properties to the following in order for the Canvas session to remain open for 4 hours:

cas.ticket.tgt.timeToKillInSeconds=14400

Interestingly, none of our other SSO-enabled applications work this way, i.e., tickets may expire, but users remains logged in.

After working with Support, they suggested I considered modifying this Per Service (https://apereo.github.io/cas/6.3.x/ticketing/Configuring-Ticket-Expiration-Policy.html#per-service, "The expiration policy of ticket granting tickets can be conditionally decided on a per-application basis."

{
    "@class" : "org.apereo.cas.services.RegexRegisteredService",
    "serviceId" : "^https://.*",
    "name" : "Sample",
    "id" : 10,
    "ticketGrantingTicketExpirationPolicy": {
      "@class": "org.apereo.cas.services.DefaultRegisteredServiceTicketGrantingTicketExpirationPolicy",
      "maxTimeToLiveInSeconds": 5
    }
}

This seemed logical enough, but I haven't tested.  Besides, this appears to be a 6.x thing and not 5.2.

Is there a workaround for 5.2.x where I can just increase this value for Canvas, I assume in services:

cas.ticket.tgt.timeToKillInSeconds=14400

  "@class" : "org.apereo.cas.services.RegexRegisteredService",
  "serviceId" : "^https://canvas...

Thanks a lot.

Bill

[Misagh]

> Instructure's Canvas (LMS) oddly links session timeouts to CAS' Ticket Expiration Policy. So, as I understand it, with the default Ticket Expiration Policy of 2 hours, Canvas sessions are automatically logging out users because Instructure chose to tie their Canvas-user session limits to CAS tickets. I had to increase the value in cas.properties to the following in order for the Canvas session to remain open for 4 hours:
> cas.ticket.tgt.timeToKillInSeconds=14400

Sure, but this has nothing to do with the Canvas session; they are
still logging people out after 2 hours, etc. There is no way they can
tell what the CAS SSO session is, and this information is not
available anywhere to an app. So by "tied it", I think you mean that
they hardcoded "2 hours" in their config because that's what they
believe CAS would do by default for the idle timeout.

What is really happening is, they log the user out after 2 hours; then
at session loss, Canvas redirects the user back to CAS, and CAS has a
longer SSO session, so the user is not prompted for credentials and
goes right back into canvas.

> Interestingly, none of our other SSO-enabled applications work this way, i.e., tickets may expire, but users remains logged in.

That makes sense; applications manage their own session, and while you
may have lost SSO, the application has no need to re-auth the user
because it has a longer session expiration policy. When it does, and
there is no SSO, they get asked for credentials again.

> After working with Support, they suggested I considered modifying this Per Service (https://apereo.github.io/cas/6.3.x/ticketing/Configuring-Ticket-Expiration-Policy.html#per-service, "The expiration policy of ticket granting tickets can be conditionally decided on a per-application basis."

I assume you mean Canvas support; That is not correct. It will have no
effect on this issue. CAS will not and cannot manage the application
session. If you want the application to not log users out after X
number of hours, ask and modify the application to not log users out
after X number of hours :)

> Is there a workaround for 5.2.x where I can just increase this value for Canvas, I assume in services:

Not without custom code, lots of it, leading to hair loss and possibly
covid. To control the application session timeout, you should modify
the application. CAS has no control over what happens inside the
application.

The only "workaround" is what you have done; to increase the sso
session expiration time to accommodate canvas, at the expense of
affecting the relationship between the global SSO session and all
other applications. As I said, canvas will continue to log users out;
users might lose data, etc. The difference is, they won't be asked to
reauth by CAS because you increased the global sso session timeout.

You might have read this already:
https://apereo.github.io/cas/6.3.x/installation/Logout-Single-Signout.html#sso-session-vs-application-session

[Richard Frovarp]

Does single logout trigger upon CAS session expiration? I would expect
not, but maybe there's a setting to flip that? Or maybe something else
is triggering single logout at two hours, and that is triggering
Canvas?

[Bill Scully]

> cas.ticket.tgt.timeToKillInSeconds=14400

Sure, but this has nothing to do with the Canvas session; they are
still logging people out after 2 hours, etc. There is no way they can
tell what the CAS SSO session is, and this information is not
available anywhere to an app. So by "tied it", I think you mean that
they hardcoded "2 hours" in their config because that's what they
believe CAS would do by default for the idle timeout.

Somehow it is somehow related, because if I alter this value, the CAS session follows suit.  What I mean is, if I change cas.ticket.tgt.timeToKillInSeconds to 4 hours, the Canvas session will last 4 hours.  If I change it to 8, Canvas automatic logouts won't occur until the user has been logged in for 8 hours.  It seems that somehow they have associated the Canvas session to the ticket time (cas.ticket.tgt.timeToKillInSeconds).

 

What is really happening is, they log the user out after 2 hours; then
at session loss, Canvas redirects the user back to CAS, and CAS has a
longer SSO session, so the user is not prompted for credentials and
goes right back into canvas.

Again, this all depends on what the value of cas.ticket.tgt.timeToKillInSeconds is.  Whatever I make this is how long the Canvas session lasts and seems to be unique to Canvas.

 

> After working with Support, they suggested I considered modifying this Per Service (https://apereo.github.io/cas/6.3.x/ticketing/Configuring-Ticket-Expiration-Policy.html#per-service, "The expiration policy of ticket granting tickets can be conditionally decided on a per-application basis."

I assume you mean Canvas support; That is not correct. It will have no
effect on this issue. CAS will not and cannot manage the application
session. If you want the application to not log users out after X
number of hours, ask and modify the application to not log users out
after X number of hours :)

Yes, this is what Canvas Support suggested I do.  I agree and find it strange that their application would base the Canvas session timeout on CAS' cas.ticket.tgt.timeToKillInSeconds.  However, it apparently does as I can control the how long a Canvas session lasts by altering the cas.ticket.tgt.timeToKillInSeconds value.

 

> Is there a workaround for 5.2.x where I can just increase this value for Canvas, I assume in services:

Not without custom code, lots of it, leading to hair loss and possibly
covid. To control the application session timeout, you should modify
the application. CAS has no control over what happens inside the
application.

Funny!

I am no expert, but I think it might if they have programmed their application to check whether a ticket is dead or alive?  It appears that this is what they have done.

 

The only "workaround" is what you have done; to increase the sso
session expiration time to accommodate canvas, at the expense of
affecting the relationship between the global SSO session and all
other applications. As I said, canvas will continue to log users out;
users might lose data, etc. The difference is, they won't be asked to
reauth by CAS because you increased the global sso session timeout.

This is what I am hoping I can do Per Service.  Is that not what this is about - https://apereo.github.io/cas/6.1.x/ticketing/Configuring-Ticket-Expiration-Policy.html#per-service?  Bear with my ignorance, but "The expiration policy of ticket granting tickets can be conditionally decided on a per-application basis."  If I can, in fact, configure an expiration policy per service and can set the cas.ticket.tgt.timeToKillInSeconds (or maxTimeToLiveInSeconds) value independently,  does this mean that the only way I can achieve this result is by using CAS 6.x?

In the words of Canvas Support, "We can't advise on exact specifics for authentication provider configurations, but an extension of the expiry time for Canvas specifically would need to be configured within the Ticket Expiration Policies in CAS. As far as I understand, it should be possible to add conditional expiry polices for specific applications while unspecified applications use the default. But, this would need to be configured in CAS, not in Canvas. "

It sounds as if cas.ticket.tgt.timeToKillInSeconds should not determine whether the application ends a session or not, but it appears that somehow Instructure had built their application so that the ticket expiration policy governs the Canvas session timeout.

Is 6.x my only hope of managing per service expiration policies to control Canvas timeouts?

Many thanks.

Bill

[Bill Scully]

Does single logout trigger upon CAS session expiration? I would expect
not, but maybe there's a setting to flip that? Or maybe something else
is triggering single logout at two hours, and that is triggering
Canvas?

 

According to Instructure Support and my experience, yes.  Whatever I set to cas.ticket.tgt.timeToKillInSeconds is how long the Canvas session lasts.  If I set it to 8 hours, the Canvas session lasts 8 hours.

[Richard Frovarp]

Then disable single logout on Canvas? I don't use single logout, but there should be a variety of ways of doing so, even if it involves providing bogus URLs that don't work to systems that insist on them.

[Ray Bon]

Bill,

Another possibility, Canvas is using is a proxy ticket. 

Does your service definition allow proxying?

Canvas could have a server side thread that probes cas proxy. Cas will return a proxy ticket until TGT life ends. When it fails, Canvas would kill the user session.

I suppose there is the possibility of using a hidden iFrame to periodically load the cas login page, and check for a ST in the response.

Ray

On Fri, 2021-03-05 at 11:17 -0800, Bill Scully wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@uvic.ca

I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations.

[Bill Scully]

Then disable single logout on Canvas? I don't use single logout, but there should be a variety of ways of doing so, even if it involves providing bogus URLs that don't work to systems that insist on them.

I did not see that as an option nor did they suggest it as a solution.  Sounds good to me, tho. 

[Bill Scully]

Hi Ray,

Another possibility, Canvas is using is a proxy ticket. 

Does your service definition allow proxying?

I would say, no.  It's pretty straightforward: 

{

  "@class" : "org.apereo.cas.services.RegexRegisteredService",

  "serviceId" : "^https://[omitted]/.*",

  "name" : "Canvas",

  "id" : [omitted],

  "evaluationOrder" : [omitted]

}

I looked at what I think covers proxy ticketing (https://apereo.github.io/cas/5.2.x/installation/Configuring-Ticket-Expiration-Policy.html#proxy-ticket-policies), but didn't see how to configure.

Any example I could try?

Thanks.

Bill

[Mike Osterman]

Hi Bill,

I was dealing with people getting logged out Canvas frequently, and ended up changing a couple config properties. I had our CSM team set the Canvas-side timeout really high, but it didn't work. There's something unusual about the way the Canvas application interacts with CAS protocol. I had checked for callbacks from the Instructure servers, but it really does seem to be managing the session after the initial SSO flow. By the way, do you use a Discovery URL? That's when our session behavior seemed to change, but it may just be correlation rather than causation.

I eventually set two properties and got it to behave as expected, but never figured out which one did the trick:

cas.ticket.tgt.timeout.maxTimeToLiveInSeconds: https://apereo.github.io/cas/5.2.x/installation/Configuration-Properties.html#timeout

AND

server.session.timeout: https://apereo.github.io/cas/5.2.x/installation/Configuration-Properties.html#web-application-session

It sounds like you've found that it was the first one, so I wanted to corroborate that for you. 

I just ended up setting these properties server-wide in cas.properties, which isn't ideal, because you have a single service dictating timeout behavior for all services using CAS.

I've also considered switching over to using CAS's SAML2 IdP functionality for Canvas, but need to wait for an appropriate time to make that change.

Finally, so as not to hijack the thread and keep the proxy ticket service configuration comment from Ray alive, I think this is how the service would be configured for it:

https://apereo.github.io/cas/5.2.x/installation/Configuring-Service-Proxy-Policy.html

I did look for server-side traffic from Canvas as Ray suggested, but didn't find any as mentioned above. I just checked for an iFrame, which would be client-side traffic, but didn't see anything in the Network tab of developer tools.

-Mike

--
- 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+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/de81107e-2895-4ac6-8241-c0337a0ccfb6n%40apereo.org.

[Richard Frovarp]

It's doing something with Single Logout. Turn it off / block it, or something:

https://community.canvaslms.com/t5/Integration-Documents/Configuring-CAS-and-Canvas-Authentication/ta-p/387390

Look at the end for "User is randomly logged out of Canvas"

[Richard Frovarp]

https://apereo.github.io/cas/5.2.x/installation/Logout-Single-Signout.html


Usage Warning!
Single Logout is turned on by default.

Documentation states that it will trigger when the TGT is explicitly
expired, which I think means calling the logout end point.

On Fri, 2021-03-05 at 21:17 +0000, 'Richard Frovarp' via CAS Community
wrote:

[Ray Bon]

Bill, Mike,

The combination of timeToKillInSeconds and maxTimeToLiveInSeconds provides a sliding window for TGT lifetime. Every request for a ST (or PT) will extend the life of the TGT by timeToKillInSeconds up to maxTimeToLiveInSeconds.

So, since Canvas is not using a proxy request, and does not have a hidden iFrame, it must be probing Cas near its session end (as Misagh mentioned). [Could javascript be used to probe Cas?]

One could look at the cas logs to see the request(s).

I set my local with very short TGT life time to test repeated login and ticket expiry behaviour (this would not be practical in production):

cas.ticket.tgt.maxTimeToLiveInSeconds=300

cas.ticket.tgt.timeToKillInSeconds=120

Ray

On Fri, 2021-03-05 at 12:41 -0800, Mike Osterman wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

-- 

[Mike Osterman]

Thanks, Ray, I'll look in my logs again. 

[Bill Scully]

On Friday, March 5, 2021 at 12:53:52 PM UTC-6 richard.frovarp wrote:

Does single logout trigger upon CAS session expiration? I would expect
not, but maybe there's a setting to flip that? Or maybe something else
is triggering single logout at two hours, and that is triggering
Canvas?

I wasn't even aware of SLO, so I've looked it up, disabled it, and am giving it a try. 

 

[Bill Scully]

On Friday, March 5, 2021 at 1:33:58 PM UTC-6 Ray Bon wrote:

Another possibility, Canvas is using is a proxy ticket. 

Does your service definition allow proxying?

I am not aware that it does.  However, I'm giving Single Logout a try... 

 

[Bill Scully]

Hi,

I simply wanted to let you know that by disabling SLO globally, Canvas session timeouts were managed by their own application settings and not governed by the Ticket Expiration Policies as before.

I need some time to think through whether this is an acceptable workaround and to understand and process the expert advice that has been given in this thread.  I may likely have a follow-up question or two, but figured I have some learning to do before I try to somewhat intelligibly try and interact with those that have been helpful this far.

Thanks to all of you for your guidance, especially to @richard.frovarp for suggesting I have a look at SLO.

Bill