I just remembered something that might be further help to you.
When a TGT expires, the default ticket registry cleaner kicks in and will then invoke a logout manager which would then execute the submission of logout notifications. The same logout manager is used to do the same function when you explicitly invoke the logout endpoint. While by default the two scenarios share the same logout manager instance, you can certainly create a separate logout manager that is exclusively used for the ticket cleaning process, and you can set it such that it disables the sending of logout requests. As such, the only way you actually would receive SLO callbacks is when you invoke the logout endpoint. This is of course assuming that you're using the default ticket registry cleaner. From: Misagh Moayyed [mailto:[email protected]] Sent: Friday, August 14, 2015 8:11 AM To: '[email protected]' <[email protected]> Subject: RE: [cas-user] single log out and login-webflow.xml Regardless of how your TGT expires, when it does and whether it's manual or automatic via the expiration policy, SLO will initiate. You no longer have an SSO session, and you will be logged out every application you have authenticated to via CAS. Starting with 4.1 I think, you will have the ability to turn off SLO on a per application basis. If you have applications that tend to stay in use longer than your SSO session, you can exclude those from SLO, and when the user logs out, simply redirect that logout to the CAS logout and kill the session entirely. Another possibility is, your CAS client could keep your session alive by sending a heartbeat signal. This depends on your application and the client, whether it provides that feature. Even with that capability, assuming you use the default expiration policy the signal is only going to extend your inactivity timeout. Once you pass the hard timeout on the application side, you're back to the same issue. Most tend to turn off SLO entirely, for reasons that are SLO-specific and less CAS-specific some of which you have run into. From: Lapanja, Bob@POST [mailto:[email protected]] Sent: Thursday, August 13, 2015 2:10 PM To: [email protected] <mailto:[email protected]> Subject: [cas-user] single log out and login-webflow.xml Using 4.0.0 I'm configuring single log out on some services and I have encountered a situation I would appreciate some clarity on. For this particular use case, we want the logout callback to be called if the user visits /cas/logout directly, but not when the TGT expires and is cleared out by the registry cleaner (accomplished thanks to logUserOutOfServices). Some users may spend a long time working in a single application. However, after doing some testing, I came across a third situation I hadn't considered. The user signs into ServiceA and continues actively using it, keeping the application session alive past the point where the TGT expires. The user then attempts to sign into ServiceB. At this point, it seems that login-webflow checks the TGT for validity, and if it is invalid calls terminateSessionAction.terminate, which fires the logout callbacks and logs the user out of ServiceA. Since this seems to be the same function called during logout-webflow, does that mean that this scenario must be considered to be the same as if the user explicitly visited /cas/logout, triggering the same logout callbacks? Since some (many) of our users have no concept of the distinction between the application session and the PASS session, the logout could be unexpected and the aborting of their active work could be frustrating. Am I missing something relevant about how people manage SLO's and users that may spend a lot of time in a single application at a time? Thank you for any information. -bob -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
