[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] handling of multiple SP logout
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]