Giuseppe Sarno wrote on 11/2/2005, 12:15 PM:
in
the section 3.7.3.2 (in case request received at the Session authority)
it says:
starting
at 2628:
Terminate the
principal's current session as specified by the <saml:BaseID>, <saml:NameID>,
or <saml:EncryptedID> element, and any <SessionIndex> elements present in the logout
request message.
It
doesn't say : If no
<SessionIndex> elements are
supplied, then all sessions associated with the principal MUST be
invalidated.
I'm
assuming it would be the same case as 3.7.3.1.
I think it would
be different. At most it would say "terminate any sessions that have
been associated with that SP", but I think that the SP should be
required to specify the session index if it was provided on the
authentication assertion (I looked at the spec, but I couldn't find a
positive statement as to this being the case -- although I think it
should be a MUST). I've submitted an errata request for this to be
clarified.
The "no ID" on the IdP driven logout is an optimization allowing the
IdP to shutdown all sessions at the SP with one call. There probably
shouldn't be any reverse optimiaztion as an SP should not be able to
have an impact on sessions that are not associated with it.
Now
Let's say I'm Principal: PRINC and logged as USERA on SPA using my
Laptop and (SessionIndexA),
USERB_C
(but still same principal) logged on
SPB(sessionindexB)/SPC(sessionindexC) using my PDA
Now
if USERB_C logs out from SPB (then a Logout request is sent to the IDP)
there are 2 options:
1)
it could send a logout request with SessionIndexB.
2)
it could send a logout request without SessionIndexes.
In
case 1 SessionInextB session for the principal PRINC is killed.
In
case 2 from what the spec says (core all sessions associated with the principal MUST be
invalidated.)
As I said above, I
think that the SP should be required to send the Session Index if it
was in the assertion used to establish SessionB (athouhg I can't find
anything that says that explicitly). However, even lacking that, I
don't think that an SP should be authorized to end sessions that were
not associated with the SP (although the IdP may allow "trusted" SPs to
do so when the reason is an "...:admin" because of the thought that if
it wasn't user initiated there may be something strange going on and
the IdP may want to play it safe -- obviously this is not a part of the
SAML spec, but I think that a cautious IdP may do this, especially with
partners that they "trust").
Conor
