logout and misc Qs --shib idp
fox at washington.edu
Thu Nov 8 16:35:44 EST 2012
At UW, when someone clicks a logout button, even a Google logout,
we clear the local shib session and send them to our weblogin
page where they see:
You have successfully logged out of ...
You are still logged in to the weblogin service as <userid>
To protect your privacy and prevent unauthorized use, completely exit
your Web browser when you are finished browsing. ...
Quite clearly the user could go back to the application and
silently reauthenticate using the 'still logged in' session.
That's the way Bob said it should work. Who are we to disagree.
It is simply not possible to log a user out of every application.
Some of them are not even shib initiated, and a user may not know
which are which. You do them a disservice to claim that they are
somehow 'globally' logged out. The only responsible course is to
inform the user how to clear the browser's sessions. That's harder
now, but it is not impossible.
As for users using a public kiosk where they cannot close the browser,
maybe they shouldn't do that.
On Tue, 6 Nov 2012, Steven Carmody wrote:
> Date: Tue, 6 Nov 2012 06:33:53 -0800
> From: Steven Carmody <Steven_Carmody at brown.edu>
> To: users at shibboleth.net
> Reply-To: Shib Users <users at shibboleth.net>
> Subject: Re: logout and misc Qs --shib idp
> I think everyone would agree that there's no silver bullet for the SLO
> issue; current protocols and current "standard practice" for application
> development preclude having any sort of silver bullet.
> That said, I've seen a number of suggestions in this thread that strike
> me as reasonable partial steps (obviously I've just cut/pasted from
> various msgs). I'm wondering what we can do to either share work that
> we've done in these areas (as individual sites) or encourage their
> inclusion in any potential IDP 2.4 release:
> 1) I think a checkbox during login to bypass SSO on shared machines is a
> fairly crucial feature at this point to at least allow users with clue
> to protect themselves.
> 2) Time permitting, we will still be looking at trying to build an
> IdP-only logout mechanism that formally clears that state using the
> standard protocol.
> 3) a few more samples/examples of what various institutions have done
> with an IdP-associated page to remove the IdP session and put out some
> 4) USC also had an interesting approach to logging users out of some of
> the local SSO-protected apps that one might use Shib for; I don't know
> if they are still using that or not. (Russ and/or Brendan?) I know they
> had shared a sample back when Illinois was first setting up Shib for use
> with Google, and Google allowed one to register a URL to send the user
> to after logging out of GAE. That was a page presented by the IdP that
> included a number of images, with each image invoking the Logout page of
> one of their SPs. I don't think (at least at the time) that they tracked
> which of those SPs you might have invoked during your browser session,
> they just picked a set of the "most sensitive" (my
> words/characterization, not theirs!).
> 5) and promulgating on our campuses this more general advice:
> You protect the device itself, and lock it's screen when not
> in use. This also protects all local data and other applications on
> the machine.. I said you've got much larger problems to worry about than
> SLO then, e.g. key loggers.
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users