> The mislabeling > causes most non-technical folks to want to implement this feature, > expecting that it would actually "log out" of all the applications > that have been visited.
I don't see how it's mis-labeled. In the best case and with proper configuration it does exactly what you described above. > In practice this is difficult (impossible?) to achieve on an enterprise scale. Indeed the best case is rare in most environments, especially enterprise ones. > * There doesn't seem to be a path for consistent and reasonable user > experience. Under good to fair conditions, reasonable user expectation can be met when the user logs out of CAS and closes the browser. > * How does the user know which services may have had there application > session invalidated and which didn't participate fully in the SLO > callback? If we made logout calls synchronous, which would likely kill usability in enterprise environments, it would be possible to list all the applications that responded with a 20x response to the LogoutRequest message sent by CAS. Of course there's nothing to say that the request actually resulted in client application session termination. > * Even if the application session was invalidated at the server, there > may still be confidential information left on the screen, window, tab, > etc. Thus our recommendation to close the browser. > * What is the user experience after the SLO, when the user decides to > continue working. The user should expect that any applications protected by CAS have ended and that reauthentication should be required for subsequent access. > * Technically requires custom integration for each service. Same as CAS integration in general, but possibly adds additional concerns. I should note that careful application of renew=true with aggressive session timeouts can help mitigate badly-behaved CAS-enabled apps that have trouble with SLO. But there's no escaping that SLO is difficult both technically and practically in terms of user expectations, which I believe were the points you intended to make. M -- 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-dev
