IdpSession Logout Problems

[Skylar Hansen]

<<[M]y SP could pull this off [...] if I take out the requirement that
the <<front channel logout of a session actually be accompanied by the
cookie <<for that session. I've leaned toward doing that, and just
assuming that <<requiring the message be signed is enough to prevent
people logging off <<others' sessions.

It would be great if it were possible to keep track of which SP's
contacted / logged in to / out of the Idp per user and when in a query
able (perhaps database or xml) format. I would want to store records of
the user name, user agent, IP address, SP connection date/time,
connection expiration date/time, etc along with the session ID and some
kind of status code (connected, disconnected, attempting logout,
attempting login, unknown, etc.) 

I haven't thought all of this through, but it would makes sense to me if
the SP could do a double check for a valid Idp session in the Idp
session database periodically and then, if there isn't a valid Idp
session found it would update the session records and attempt to logout.
Something along these lines, I would think, would allow for a more
complete logout even if someone had signed in on multiple browsers. The
UI could at least report an accurate status of complete or partial
logout. 

<<And then you have all the apps doing their own sessions that can't be
<<cleared via a back channel.

You could argue that if it isn't a Shibboleth app, then it is beyond the
scope of Shibboleth. I think most people would understand that.

<<As a practical matter, it's also the case that in any medium term,
every <<SAML logout you do will be partial, since you won't see mass
adoption of <<the capability. Can we explain that to users? And even if
we could, isn't <<the explanation simply that the behavior your people
are up in arms about <<is in fact the reality? 

It seems that avoiding ambiguity with users works best when possible. My
management actually insisted that I NEVER tell users about Shibboleth.
He doesn't even want to hear the word outside of our office. 

I implemented a solution that seems to have satisfied our users for the
moment. In order to get it to prevent people from going into their web
histories and clicking on pages that haven't logged out, I wrapped some
of the external apps inside framed portal pages. This is definitely an
illusion more than anything. 

I also have the portal doing a bunch of logouts from a custom portal
logout page. When those are done, the portal redirects to a custom
logout.jsp page on the Shibboleth Idp that deletes the Shibboleth
_idp_session and Shibboleth JSESSIONID cookies, and then invalidates the
session. 

This solution prevents people from "going around the loop" and getting
right back into the portal that they just signed out of, and seems to
have calmed the storm for now.

(Thanks again Ken and Dan :)