In terms of incremental progress: I'd like to suggest the improvement of
making the single log out callback opt-in via the services registry.
Currently many (most?) CAS using applications are not prepared to
properly handle the callback, so calling back to them is just noise.
With that metadata in hand, it becomes more feasible to consider
enhancing the user experience of the login screen to report to the user
which services the CAS server will and will not attempt to sign out via
back-end callback in cleaning up the particular terminated single
sign-on session.
Andrew
On 08/02/2011 02:05 PM, William G. Thompson, Jr. wrote:
I suspect that "Single Sign-Off" or if you prefer Single Log Off
(SLO), or as I prefer the "clean up server side application session
resources that are no longer needed" feature, doesn't really behave in
a way that would meet the expectations of users. 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. In practice this is difficult (impossible?)
to achieve on an enterprise scale.
* There doesn't seem to be a path for consistent and reasonable user
experience.
* How does the user know which services may have had there application
session invalidated and which didn't participate fully in the SLO
callback?
* Even if the application session was invalidated at the server, there
may still be confidential information left on the screen, window, tab,
etc.
* What is the user experience after the SLO, when the user decides to
continue working.
* Technically requires custom integration for each service.
Do I have this about right? Do others have different experiences with
this feature?
Bill
--
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
