[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] handling of multiple SP logout
> Fair enough on the first point -- there's probably a bunch of errata or > minutes that led to the current decisions of whether to use > Requester/Responder. [RSP] We'd have to jump in the WAYBACK machine for those notes... IIRC it was back in the SAML 1.0 days (gosh I suddenly feel REALLY old!). > The Liberty conformance tests are very light on negative > (or error) tests related to msg processing. So these types of decisions have > no propagated to the tests yet. > > As for disabling it, yes, physically removing the endpoint would work, but > this is a configuration update (basically it changes a partner's original > metadata). [RSP] True. That could make dynamic on-line testing a bit more difficult since there's more coordination involved. Of course, you can just have everyone provide the 2 sets of MD up front (one with and one w/o the SLO endpoints). It is a bit more complicated, but should be workable. > > I thought Kyle was leaning more toward a disablement where the endpoint is > somehow disabled outside of the acutal applications (i.e. no application > config changes out of the norm). I.e., perhaps a hostname update on the > tester/browser, so that a redirect to the SP being discussed cannot be > completed. At least for this year's set of tests. [RSP] I agree it would be preferable to not change MD. If you are strictly relying on an etc/hosts configuration, it might work. However, it might also be more error-prone depending on whether the failures cause browser timeouts, etc. when using the recommended front-channel bindings. I think I'd still opt for the multiple configuration option. But perhaps the latter could work... > -----Original Message----- > From: robert.philpott@rsa.com [mailto:robert.philpott@rsa.com] > Sent: Monday, August 03, 2009 3:39 PM > To: Thomas Wisniewski; kyle@drummondgroup.com; security-services@lists.oasis- > open.org > Subject: RE: [security-services] handling of multiple SP logout > > > Kyle, one addition to your point, I think that Requester (being > returned from > > the SP that the user logged out locally from), is more likely the > response > > code (as opposed to Responder). I.e., the requester is asking for a > session at > > the SP that no longer exists (as Scott mentioned, the SP does not > maintain > > this). So the LogoutRequest from the IDP is no different than one > where a > > bogus session index is used. I'm not sure why Responder would ever be > the > > error case (if the SP doesn't understand the session index). > > [RSP] I strongly disagree with using "Requester". If the IdP keeps track of > the SP's to which it has provided an assertion for an SSO session, then there > is absolutely nothing wrong with the request. The fact that an SP might not > maintain any state about the user session is a responder issue... not a > requester issue. BTW, some SP's do maintain state. > > We've discussed this in the past... IIRC the consensus was that a SAML > responder should normally only use the "Requester" error status in a response > if a SAML requester sent it a message that was ill-formed or was not > conformant to SAML request generation rules. If the message is well-formed > and otherwise "valid" w.r.t. SAML rules, but the responder cannot satisfy the > request, then this is a "Responder" error. > > > > > As for disabling the endoint, this is probably impossible since this > is over a > > redirect binding. The browser would just be stuck trying to contact > the SPb > > SLO endpoint. > > [RSP] It's not impossible at all. If SP-B has no endpoint, then the IdP > should never try to redirect there and there'd be no browser HTTP request > getting stuck. That is, the IdP should skip that SP as it is going down the > list of SP's to which it needs to send a LogoutRequest. > > > > Tom. > > > > -----Original Message----- > > From: robert.philpott@rsa.com [mailto:robert.philpott@rsa.com] > > Sent: Monday, August 03, 2009 3:03 PM > > To: kyle@drummondgroup.com; security-services@lists.oasis-open.org > > Subject: RE: [security-services] handling of multiple SP logout > > > > > In the test group, we had a general agreement that if SP-B returned > an > > error > > > status, the IdP should send Success/PartialLogout to SP-A. > > > > [RSP] Yes... it's probably obvious, but for completeness you're > missing one > > additional requirement... if SP-B returns an error status to the IdP > in a > > LogoutResponse "AND the IdP successfully logs the user out of the > IdP", then > > that IdP must send Success+PartialLogout to the SP that originated the > > LogoutRequest. The IdP could somehow fail to log the user out of the > IdP. If > > so, then it would return an error back to the original SP. > > > > > > > > The area we chiefly need guidance on was the status returned when > SP-B > > > received a LogoutRequest from the IdP after it had already > terminated > > the > > > session. It appears that either Responder or Success would be > > permissible. > > > > > [RSP] IMO, yes. > > > > > The purpose of this test scenario was primarily to create a > situation > > so > > > that the IdP did return a PartialLogout status to the originating SP > > and > > > test out that functionality. Perhaps the best method to do that > would > > be to > > > disable the SP-B endpoint so that the IdP is unable to contact it. > > > > [RSP] Yep - that's how I'd test it. > > > > > > > > Kyle Meadors > > > DGI > > > > > > * * * * * * * * * * * * * * * * * * * * * * * * CONFIDENTIALITY > > > DISCLAIMER This email, including attachments, is confidential and > > > proprietary. It constitutes exclusive communication solely to the > > > addressee. Any > > entity > > > other than the intended addressee is prohibited from use of this > > > communication for any purpose. This email, including attachments, > may > > not be > > > distributed, whole or in part. > > > * * * * * * * * * * * * * * * * * * * * * * * * -----Original > > > Message----- > > > From: Scott Cantor [mailto:cantor.2@osu.edu] > > > Sent: Monday, August 03, 2009 1:12 PM > > > To: robert.philpott@rsa.com; kyle@drummondgroup.com; > > > security-services@lists.oasis-open.org > > > Subject: RE: [security-services] handling of multiple SP logout > > > > > > robert.philpott@rsa.com wrote on 2009-08-03: > > > > 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... > > > > > > I don't think you can require anything here because the SP isn't > > required to > > > remember a session once it's locally terminated. > > > > > > > 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... > > > > > > For the user experience, you absolutely SHOULD do that, but you > can't > > > require it. > > > > > > > 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. > > > > > > Right. > > > > > > > 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. > > > > > > Right. That's all spelled out, is my point. Could be clearer, but I > > don't > > > think "clear" and "logout" really belong in the same sentence. > > > > > > -- Scott > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe from this mail list, you must leave the OASIS TC that > > > generates this mail. Follow this link to all your TCs in OASIS at: > > > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > generates > > this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]