Question about session management in IdP 2.4.0

[Yaowen Tu]

So we were trying to provide a more complete SLO feature in 2.4.0 but found
that the design was incomplete, and then just left the existing code in it
as long as it doesn't break any existing feature?

Is it related to this note in the SLO wiki?

Due to a design limitation in this version, the IdP cannot access more than
one session at a time for a given subject identifier. This works okay with
transient or directed/persistent identifiers, but limits the IdP's ability
to terminate all of the sessions associated with an identifier even if that
might be useful. Secondly, because of this limitation, the
SessionIndexattribute in SAML is ignored.

One more case I want to confirm. Continuing with the scenario in my
origianl post:
1. After "Administrator" login to Firefox first and then Chrome.
2. Now "Administrator" try to do Single Logout on Fireforx, will IdP get
the session of Chrome and clean that session?
3. Now "Administrator" try to SSO on Firefox, it will still work without
password, is it?

Sorry I should try it by myself, but unfortunately I don't have a SLO
enabled SP to try right now, but I will try it later. Just hoping that I
can get an answer about that now so that I have a better understand about
what we have for IdP 2.4.0.

Yaowen


Yaowen


On Thu, Apr 25, 2013 at 4:11 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 4/25/13 6:52 PM, "Yaowen Tu" <yaowen.tu at gmail.com> wrote:
> >
> >But what I don't understand if that one index may represent multiple
> >sessions, for example in my previous example, IdP has added index
> >"administrator" to two different sessions. The later one will replace the
> >previous one in the SessionStore, then the only
> > way to retrieve the old session is through session-id, not through other
> >index. Am I understanding correctly? Did I miss anything on it?
>
> No; it's broken.
>
> >Then what is the purpose of these different kinds of index for each
> >session?
>
> Trying to handle logout without ever implementing it and determining the
> design was incomplete.
>
> The only reliable session lookup is by cookie. Nothing else will work
> predictably.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130425/c7903422/attachment-0001.html