Shibboleth Developers

[Adam Lantos <>]

On Mon, Dec 7, 2009 at 11:47 PM, Scott Cantor 
<>
 wrote:
> Adam Lantos wrote on 2009-12-07:
>> 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
>
> Acually, it is probably possible to detect that kind of thing in some cases 
> ahead of time so you can drop a local cookie indicating whether the support 
> is available.
>
> But my underlying purpose was to demonstrate that frames may not be an 
> appropriate solution here. I didn't want to rathole on it, but it just 
> doesn't work when people use perfectly reasonable privacy settings. I 
> suspected this when I started this testing, and now I know I was right.
>
> What has never been clear to me about SLO is whether one can architect a 
> generic solution that allows people to plug different UIs in front of it. 
> It's one thing to say "use the frames solution if you're ok breaking when 
> X/Y/Z is used", but it's another to say "and if you need a different UI, 
> the whole SLO framework changes and you'll have to write all new code".

The former, but one small step is missing now. After that, it would be
possible to use the good old redirect-chain plan as UI, or to present
a big, red, blinking "you must close your browser. now." text with
links to mozilla issue tracker all over the place.

> Secondly, blocked cookies *are* an issue if the SP needs the user's 
> session. If you don't need the user to be present, then you don't need to 
> do front channel logout and you don't have a problem to begin with.

You need to do front-channel logout if you have to deal with
frontchannel-only IdPs.

>
>> (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'm not going to start putting NameIDs onto URLs, not only because it's 
> ugly, but also for privacy reasons.

Yeah, that was a bad idea, indeed.

>> 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.
>
> "Most" just isn't that interesting to me. I guess this is where the pro- 
> and con-logout arguments tend to end up.

I understand that this is mostly a theoretical problem, but how much
support request is considered good enough per 50000 logouts? :)


>> 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.
>
> You can, I suppose, but such an SP would essentially have incorrect 
> metadata and that's what you're coding around.

Both sides should be as robust as they could be. If you remove
front-channel bindings from the SP, your SP wouldn't be interoperable
with frontchannel-only IdPs and lose exponentially more users than the
cookie-problem would ever mean. Even if it's against the specs, it
seems that preferring back-channel is the best thing the IdP can do if
it wants to deal with cookie problems. But this is just my two
cents...


> -- Scott
>
>
>