IdpSession Logout Problems

[Cantor, Scott]

On 10/30/11 6:46 AM, "Kristof Bajnok" <bajnokk at niif.hu> wrote:

>On 28/10/11 21:02, Cantor, Scott wrote:
>> The reason I didn't is that we already have that implemented: the back
>> channel. Why bother doing it front channel and requiring that brittle UI
>> if you can just do it via SOAP?
>
>For a couple of reasons it can be more difficult to deploy:
>  * SP clusters without shared Shibboleth sessions

Meaning the client is sticky. Yes, I guess that's true.

>  * back-channel authentication

You use signing, same as the front channel. I don't see why that's a
problem.

>  * outgoing TCP might not be allowed by some IdP cluster setups
>(firewalls or load balancers)

I don't have much sympathy for those firewall choices.

>  * front-channel is preferred when available, so the front-channel
>bindings should be removed from the SP metadata for forcing back-channel
>(I think it's quite common to have front-channel SLO endpoints for SPs)

This is true only insofar as you have to deal with implementations that
can't handle the back channel, but I admit that's a problem.

So, yes, those are a couple of legitimate reasons. I don't see a RFE filed
in Jira for this, however. I know I've rejected it in the past, but
there's no request marked Won't Fix that I can find.

>However ugly is the current UI (in the Hungarian SLO-IdP), at least it
>never lies. When SLO is not working (because of 3rd party cookies or for
>some other reason), it tells that it failed, so do whatever you can to
>log off.

Yes. But I don't believe users understand this. And if I think it's either
the common case, or will become the common case, that defeats the purpose.
But I agree that if my implementation can manage things without third
party cookies, I should support that.

-- Scott