Shibboleth Developers

[Adam Lantos <>]

On Mon, Dec 7, 2009 at 11:11 PM, Scott Cantor 
<>
 wrote:
> Adam Lantos wrote on 2009-12-07:
>> Right, that makes sense if the sessions didn't match, but the logout
>> would also invalidate the cookie itself, so I don't see any point in
>> aborting when no session was found (with the default logoutrequest
>> signing requirement, at least). Of course front-channel app
>> notification would be broken in this case.
>
> Which is the whole (only?) point in using the front channel. Front channel 
> means "the user is present" and back channel means "the user is not 
> present". I wanted there to be a clear distinction between them.

Okay, but the IdP can not decide whether the browser blocks those
cookies or not. If the SP could just fall back and use the information
in the LogoutRequest, blocked cookies were no longer an issue (maybe
front-channel notification should be extended to convey session index
to the application, so in theory it could invalidate user session like
in the back-channel case, but without the SOAP requirement - restful
notifications, anyone?).

I agree that in the blocked cookie case, normal, "per-spec" logout
would be impossible, but maybe we can make it work somehow in most of
the cases.

>> Well, at least the IdP side should have a prefer-back-channel switch
>> to control this behavior :)
>
> That would violate the profile. Front channel MUST be favored. I think that 
> applies in both directions because of the proxying that can go on.

On second thought, if frontchannel binding gave us SAML error
response, the IdP could try back-channel. That's something I can do
about this issue.

> The SP can and should make sure it exposes the endpoints it needs to. If it 
> doesn't need front-channel, it shouldn't support it. That's part of the 
> profile assumption, and is one of the reasons I implemented it this way.
>
> -- Scott
>
>
>