OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[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]