RE: [security-services] Single Logout

["Scott Cantor" <cantor.2@osu.edu>]

> Unfortunately we were not able to test out the details of SLO 
> at last week's interop. Here are a couple of issues that I 
> still have as unresolved (perhaps they are captured in Greg's 
> list re: interop items).

Nope.

> 1. SamlProf line 1199. It's not clear why this section 
> discusses how the IDP would propagate logout msgs to other 
> session participants (vs. for example the next paragraph 
> which talks about async bindings and make no reference to 
> it). In any case, the wording say "would then propagate ... 
> using a synchronous binding". Does this imply MUST, I think 
> it does and should state it.

I don't have any problem with that, but there's a basic issue here that
needs to be noted. Profiles do not change protocols, they only constrain
them. The protocol by definition requires propagation. It's redundant for
the profile to repeat all those processing rules, thus the informal language
in the profile. The MUST is already there by inference.

> And a similar stmt should exist in the async binding section.  So for
> example, if the initial LogoutRequest from SP to IDP is via SOAP, the IDP
> cannot send LogoutRequest msgs to other PS via an HTTP (front-channel) 
> binding. Correct?

Correct because that's impossible. If the initial request is SOAP, the
browser isn't sent to the IdP, therefore there's no way to use the front
channel. That's why the lanaguage in step 3 talks about the "availability of
the user agent".

> Additionally, line 1231 section 4.4.3.3, "same fashion" is 
> not strong enough, or does not imply (to me) that we are 
> discussing "bindings" as in front-channel or back-channel.  
> Instead it should say the binding used MUST be the same 
> channel as requested in 4.4.3.1.

This is incorrect. I can use any binding I want, if it's "consistent with
the capability of the responder and the availability of the user agent at
the identity provider." I wrote it that way intentionally.

By "same fashion" I simply meant that the basic transmission of the
LogoutRequest is the same as in step 1 (with all associated rules), allowing
for any binding differences. It does not mean you have to use the same
binding.

If we had a SOAP 1.2 binding, you could do SOAP 1.1 initially and then use
SOAP 1.2 to propagate. No problem. Same goes for Redirect and POST.

> SamlCore 2620-2624, leaves this open as well. I think it 
> would make more sense to say implementers should try and 
> logout at all participants and return and error in the end if 
> at least one failed (i.e., best-case effort). Thoughts?

I don't have an opinion, since I think Single Logout is kind of loony and
resetting the desktop is a better idea. It is definitely left up to
implementers now.

> 3.SamlProf Line 1191 says "If multiple identity providers are 
> involved...". How does a session (as described in the 
> sentence before this line), apply to multiple IDPs (if this 
> is thru some IDP proxy, wouldn't the proxy send the request 
> to the original IDP or IDP proxy, etc...)? SamlCore 2507-11 
> suggests there is only one IDP to send the request to.

It's not talking about SSO proxying, but a case where you might somehow have
connected assertions together from multiple IdPs as a single user session
that's being logged out. I think it's kind of obscure, actually.

As you say, for a proxy case, the session authority IdP just acts as a
session participant and starts with step 1.

-- Scott