Your analysis is correct. Even if you were able to go through the technical effort to set up a separate configuration for the logout vis-à-vis a separate CASImpl, I couldnt tell you what else could break. The sort of configuration you start to modify is buried within CAS for good reason, and adopters arent expected to modify those areas, unless you absolutely know what you are doing and have thought through all scenarios. So, if I were you, [and you have concluded the same], I would not go this route. Not to mention that touching those files would make your upgrade more difficult than it needs to be, in the long run.
I may have mentioned this, that I personally think the best approach is to completely treat the CAS session and the application session separately. SLO is all or nothing, (though in 4.1 you get the option to exclude SLO participation on an application basis) and it only works in very specific circumstances. Once you treat them separately, youll realize that even though you have lost CAS SSO because TGT is gone, your app will continue to be functional. When the user needs to log out of the application, you can kill the app session there, and optionally kill the CAS SSO session as well. Some additional verbiage on the app logout page may also be useful to help the user understand that even though you have logged out of this app, you may still have an SSO session. From: Lapanja, Bob@POST [mailto:[email protected]] Sent: Monday, August 17, 2015 12:17 PM To: [email protected] Subject: RE: [cas-user] single log out and login-webflow.xml If Im understanding what youre 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 Im 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 theyll 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 didnt 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, Im 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 its invalid), the information about what STs and applications it was mapped to is also lost at that point, so preserving the ability for /cas/logout to call them doesnt really matter, right? If I login to SessionA and SessionB, wait for my TGT to get cleaned (and it doesnt call the SLO callbacks at that point), visiting /cas/logout wont trigger SLOs for SessionA or SessionB, because it wont 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, Im 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 Im 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] <mailto:[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 youre 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 its 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, youre 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 Im 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 hadnt 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 SLOs 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] <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
