[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saml-dev] SLO Profile Question
Ok, to follow up on this slippery slope a bit more. I'm reading through the SAML Profiles spec, section 4.4.x. In reading the text, it talks about using the same binding as the initial request that comes in. So specifically, the originating Session Participant sends the LogoutRequest via HTTP (either Redirect or POST), to the Identity Provider. I'm reading the text at that point to say that the IdP should use the same binding type (given availability). So, to me, that says I should use the principal's user agent (browser) to send that LogoutRequest message to the other Session Participants. So the overall flow might be something like this: 1. Principal chooses Logout at SP1 2. SP1 constructs LogoutRequest and uses principal's browser to send it to IdP 3. IdP receives request and determines other Session Participants 4. Assuming N SP's, the flow would then be a. Use principal's browser to send LogoutRequest to SP2 b. SP2 responds to IdP with LogoutResponse c. Repeat steps a and b for each N SP's 5. After final response to IdP from SP N, clear local session at IdP 6. Issue final LogoutResponse to SP1 via browser 7. User is at SP1 So, that's one interpretation of the protocol spec. I can see it failing quite easily and not terminating the IdP session and not returning the final LogoutResponse to the originating SP as well. Another flow might be: 1. Principal chooses Logout at SP1 2. SP1 issues LogoutRequest to IdP via principal's browser 3. IdP receives request and determines other Session Participants 4. Assuming N SP's, the flow would then be a. Send LogoutRequest to SP2 directly from IdP b. SP2 responds to IdP with LogoutResponse c. Repeat steps a and b for each N SP's 5. After final response to IdP from SP N, clear local session at IdP 6. Issue final LogoutResponse to SP1 via browser 7. User is at SP1 So while all communications is via the same binding, the principal's browser is not involved with the other Session Participants. It does allow the IdP to ensure all SP's are contacted though. The principal's browser may still have local session state (cookies, etc) with those SP's but in theory the SP's will know it is invalid. Then you could modify that last one to treat the originating SP the same as all. So the IdP would send the LogoutResponse directly to the SP and leave the principal at the IdP logout screen: 1. Principal chooses Logout at SP1 2. SP1 issues LogoutRequest to IdP via principal's browser 3. IdP receives request and determines other Session Participants 4. Assuming N SP's, the flow would then be a. Send LogoutRequest to SP2 directly from IdP b. SP2 responds to IdP with LogoutResponse c. Repeat steps a and b for each N SP's 5. After final response to IdP from SP N 6. Issue final LogoutResponse to SP1 directly from IdP 7. IdP then terminates its session with the principal 8. The principal is then left at the IdP logout screen I can see all of these as meeting the spec, but is their a general practice out there of one of these? Some other variation? Am I missing a restriction somewhere in the spec for the IdP using the Redirect/POST binding directly (acting as the user agent)? thanks, Paul -- Paul Hethmon Chief Software Architect Clareity Security, LLC o) 865.824.1350 c) 865.250.3517 e) paul.hethmon@clareitysecurity.com On 10/11/11 1:05 PM, "Cantor, Scott" <cantor.2@osu.edu> wrote: >On 10/11/11 1:00 PM, "Paul Hethmon" <paul.hethmon@clareitysecurity.com> >wrote: > >>In the SAML Profiles spec document, section 4.4.2, there is a figure 3 >>showing the flow during a SLO sequence. My question is whether the final >>LogoutResponse to the initiating service provider should actually >>redirect the user's browser (using front channel) >> back to the initiating service provider? > >Message sequence diagrams are about messages only. They have no normative >implications for UI. If the binding is Redirect, then there's a redirect, >but that has no prescriptive requirement for whether it's a frame doing >the redirect or not. > >SAML only addresses what's on the wire. Whenever it tries to do more, it's >usually a mistake, and ends up causing more problems than it solves. The >attempts to mandate error handling are a good example. > >-- Scott > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org >For additional commands, e-mail: saml-dev-help@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]