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

On 10/12/11 12:04 PM, "Paul Hethmon" <paul.hethmon@clareitysecurity.com>

>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).

The response has to go back using the same type of binding. If the SP
starts with HTTP, you can't respond with SOAP (how would you?). The
propagation is a separate matter. If you knew no proxies were involved,
you could use either. Using the same type is a more cautious approach.

>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.

Right. AFAIK, nobody finds that naïve approach viable, which is where all
the frames come in (and where my browser fails).

>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.

Well, right, but SPs often simply won't support SOAP, let alone the
application issues involved.

>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:

No, you can't. There's no way to send the LogoutResponse in a SOAP request
(because nothing could come back to complete the binding). You have to use
front channel. You can use tricks and frames.

>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)?

I've never heard of that being done, but strictly speaking the problem
isn't the spec so much as the assumptions that underlie the bindings. The
client is assumed to be the user agent in terms of the interactions with
the site, and if the site can't rely on that, stuff breaks.

As to your question, I know of no general practices around logout apart
from the iframe model that doesn't work in my browsers.

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]