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. > 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<https://apereo.github.io/cas/6.1.x/ticketing/Configuring-Ticket-Expiration-Policy.html> 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 -- Ray Bon Programmer Analyst Development Services, University Systems 2507218831 | CLE 019 | r...@uvic.ca<mailto:r...@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. -- - 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/204bc65e8e57afe03e9f8d40765c8d91896ce1bb.camel%40uvic.ca.
