If I'm understanding what you're proposing correctly, I believe the default ticket registry cleaner already has a flag which accomplishes the same affect (logUserOutOfServices), and it works perfectly. The problem I'm having is when the user visits /cas/login with an expired ticket, but before the registry cleaner has cleaned it. In this case, TerminateSessionAction.terminate is called just like when you visit /cas/logout, which in addition to clearing out the TGT will also make the SLO callbacks to all of the applications. The effect is that I can disable the SLO callbacks when the ticket registry cleaner runs, but they'll still happen if a user visits a new CAS enabled application after the TGT has expired but before the cleaner has run.
Inspired by your suggestion about the logout manager I checked for pieces I could replace with my own behavior. Since /cas/logout and /cas/login use the same CentralAuthenticationService, and by extension the same logout manager, disabling SLO callbacks in one disables them in both. It seemed like I would have to have a separate implementation of CentralAuthenticationService that didn't perform the client logouts when destroying the tgt, and then set up a separate TerminateSessionAction for /cas/login that used the new CentralAuthenticationService. But honestly, based on your feedback and after researching this a little deeper, I'm starting to think what I want to do is nonsensical. When the TGT is destroyed (whether by the registry cleaner or by /cas/login if it's invalid), the information about what ST's and applications it was mapped to is also lost at that point, so preserving the ability for /cas/logout to call them doesn't really matter, right? If I login to SessionA and SessionB, wait for my TGT to get cleaned (and it doesn't call the SLO callbacks at that point), visiting /cas/logout won't trigger SLO's for SessionA or SessionB, because it won't know about them anymore. It seems as though an application may have to be either all in or all out on SLO, and without a heartbeat type mechanism like you mentioned earlier for the application to use to ping CAS, I'm not sure some of my long running applications can be all in. I need to think on this a little more with this new perspective, perhaps there is a solution still out there I'm overlooking. Thank you for the information, I appreciate your patience while I tried to get a better handle on the full picture. -bob From: Misagh Moayyed [mailto:[email protected]] Sent: Saturday, August 15, 2015 10:45 AM To: [email protected] Subject: RE: [cas-user] single log out and login-webflow.xml 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]<mailto:[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]<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
