RE: [security-services] handling of multiple SP logout

[<robert.philpott@rsa.com>]

See below, but I think we could have an issue in defining the "correct"
behavior here w.r.t passing or failing a conformance test...

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Monday, August 03, 2009 1:37 PM
> To: 'Kyle Meadors'; security-services@lists.oasis-open.org
> Subject: RE: [security-services] handling of multiple SP logout
> 
> Kyle Meadors wrote on 2009-08-03:
> > 1. If the local session is ended at SP-B, is the proper status
Responder
> > to the IdP or should be Success? If Success, how else should SP-B be
> > "configured" to return a non-Success status apart from ending is
local
> > session?
> 
> If it has some way to know that the session it's being asked to
terminate
> was already terminated, then it can pretend to do so and return a
Success.
> Otherwise it wouldn't know what the session was and would have to
respond
> with an error and optionally indicate the session wasn't found/active.
It's
> implementation and probably timing dependent.

The spec isn't really precise on this use case. I personally think it's
best to pretend it worked and send "success" because of the spec wording
related to #2 below...

IMO, however, w.r.t. conformance testing, I'd be hard pressed to say
that returning an error status (i.e. Responder) would violate the spec.


> 
> > 2. If SP-B does return a non-Success status to the IdP, what is the
status
> > in the LogoutResponse from the IdP back to SP-A?
Success/PartialLogout?
> > Responder/PartialLogout? Success?
> 
> The protocol covers this. If the IdP action succeeds then its response
is
> Success. If there are reasons to do so, like here, you add
PartialLogout.

To be more precise, the "IdP action" Scott is referring to is whether
the IdP is able log out the user's session at the IdP.  It is not
related to what happens at any of the SP's.  The spec states: "If the
session authority [i.e. the IdP in this specific scenario] successfully
terminates the principal's session with respect to itself, then it MUST
respond to the original requester, if any, with a <LogoutResponse>
message containing a top-level status code of
urn:oasis:names:tc:SAML:2.0:status:Success." And "In the event that not
all session participants successfully respond to these <LogoutRequest>
messages (or if not all participants can be contacted), then the session
authority MUST include in its <LogoutResponse> message a second-level
status code of urn:oasis:names:tc:SAML:2.0:status:PartialLogout to
indicate that not all other session participants successfully responded
with confirmation of the logout."

Of course if the IdP receives an error from an SP due to item #1 above,
technically it has to report back a "PartialLogout" second-level status
to the SP that originated the LogoutRequest.

Rob