IdpSession Logout Problems

[Peter Schober]

* Skylar Hansen <shansen at randolphcollege.edu> [2011-10-28 16:52]:
> At my organization we recently went live with a Shibbolized portal and
> we are having some severe issues with users being able to logout.

While nothing I write below is new or will help with people screaming
at you and demanding the IdP admin's head on a plate, I do think it's
necessary to look at the percieved problem space in more detail.

Logout is not an end in itself, even if it's sometimes presented that
way, e.g. in your android phone story below.
Logout usually is (a) a means to prevent unauthorized access to your
account and your (and possibly other's) data. And (b) it's sometimes
used to implement account switching (e.g. to check the LMS with
student vs. teaching assistent permissions).
The former case is what we're usually talking about here, the latter
often is the consequence of having to use lesser software (that
doesn't provide such a functionality on its own) or of an
institutional tradition of handing out one account per
role/affiliation one has at the instition, creating the problem of
account switching in the first place (also owing to insufficient IdM &
access management practices, of course).

People working in offices, on their individual PCs, laptops or
workstations have several other ways to protect their webbrowser:
First there's physical security, i.e., doors with locks on them.
And since active web sessions are by no means the only threat, the
desktop and all its data and applications will need to be protected
anyway, so at least locking the screen (manually when leaving,
automatically from a "screensaver") is inevitable anyway. Doubly so in
shared office spaces.
No need for Web SLO there, and it wouldn't be sufficient.

> Another person logged in to our portal via her android phone, and
> then clicked logoff, but found that she was able to get right back
> into her email.

Why should I want logout from a web application from my personal phone
(or notebook or netbook or workstation)? The device itself needs to be
protected with a password, passphrase, guesture, PIN, fingerprint,
iris scan or what have you. And physical security, again, since you
don't want it stolen either.
[ I do find it highly ironic that now "logout" comes back as
"conventional wisdom" as a demand from users and business people to
security staff. Possibly paraphrasing Scott: "We can't be bothered
with reality, just give us a logout link. You said to always logout
yourself!" ]

So IMHO that leaves only two legitimate scenarios where logout
might become a problem:

* Public shared computers -- your student lounge, library, PC lab, all
of which you can control/influence in some way in your own
institution, by educating the people running things (or getting
policies created and enforced) to configure the thing safely (i.e, not
using FF's b0rken session restore, allowing the browser/desktop to be
exited completely).
Of course then there are all the other public computers you have no
way of controlling, in the worst case some shady internet cafe while
you're on holidays. But in almost all of these places my concern would
be bigger to have my credentials themselfs "logged"/copied directly
from the desktop than someone reusing a leftover session when I walk
away. Also since you often pay for these services the desktop and
browser sessions usually expire when your session expires.
If in doubt, don't use the system at all. 
Also with netbooks and other personal mobile devices, GSM/3G roaming,
phonecards, open/free fireless networks, etc. people depend less on
the PC infrastructure in such internet cafes/call shops, meaning fewer
shared public computers (I think). Which leaves us with...

* Account switching. Might not be a problem at your institution. I've
been told it's a problem in ours and for the moment I insist on this
being an application (integration) problem. Implementing "Act as..."
in every application that needs this is of course lots of redundant
work (if you can change the app at all, less so today with SaaS/ASPs),
requires some IdM/AM infrastructure (who may proxy for whom) and
pushing the feature request to the WebSSO system is an easy way out.
In the days of local authentication at each resouce logout + login
with some other account was easy (if less than elegant/desirable), SSO
only made the problem appearent.
I'm not convinced that anything one comes up to deal with this
(e.g. mandate single/global logout or do away with standards-based
identity federation!) beats using another browser (or another
instance of the same browser), in any respect. The number of people
who routinely need this is limited and the number of accounts these
people want/need to use is limited as well (so we're not talking about
juggling 13 different browser instances).

Note that at the same time there's a demand for desktop SSO (cf. the
recent SPNEGO thread), which I image would make any kind of logout
even more fun (but then locking the desktop alone works today, without
SLO). Looking forward to people recommending complete logout from the
desktop to change the account used on an arbitrary web page on campus.
But no, those other accounts are not permitted to login to your
managed PC... we're back to "use another browser" (one not properly
configured for SPNEGO)? ;)
-peter