Shibboleth Developers

["Scott Cantor" <>]

> In this case, not even trying to use SLO.

Not single, but it's still logout. How would the IdP know that a request
back to it within a given session was supposed to be "not the same session"?

I think realistically you have the choice of doing logout (which the users
won't do anyway) or avoiding the creation of a session to begin with.

> The users "logout" of their
> session with the SP and leave the browser open for the next person who
> sits down at the community computer. I would certainly like to force
> them to close the browser, but with IE, that's easier said than done.
> The user can "close" their window but leave the process still running
> and maintaining the sessions.

I keep hearing this but haven't observed it on any machines I use for years.
Probably not since Windows 95 actually. I'm sure it's possible, but I don't
think it's as prevalent as some think. I certainly can't imagine why a
locked down shared machine would be more likely to suffer from that issue.

In any case, it's probably past time somebody try and document when it
happens and when it doesn't.

> For me, whether wrong or right, my users only ever have a single principal
> name. So for now I'll go the route of explicitly nulling out the IdP
session
> information in my login servlet. I'm sure it will bite me later.

I think there's two points:

Disposing of the session immediately after login seems more sensible to me.

Another thought is that if there's demand and wide acceptance of a UI for
logout that explicitly ignores the goal of single logout and just clears the
IdP session, it may be worth simplifying the attempt to create a full-blown
SLO implementation and just creating one that does that job alone.

-- Scott