IdpSession Logout Problems

[Cantor, Scott]

On 10/28/11 2:28 PM, "Skylar Hansen" <shansen at randolphcollege.edu> wrote:

>I worry in the long term, once these weaknesses are noticed by users -
>that credibility would become even more damaged than it would without
>logout in the first place.

That's the main reason we haven't shipped a trivial IdP logout
implementation that does a hardwired "partial" logout by just dropping the
IdP session.

>In fact, when we first launched the portal w/ Shibboleth, for the very
>reasons you mentioned below - we didn't HAVE a logout button. It was
>decided in a series of meetings, at my adamant protest actually, to add
>the button.

I think that's definitely a mistake. If nothing else, such a button should
take you to a page saying "we can't".

>I think you're right, but I think it is also a case of people not knowing
>what they have until they lose it. Our helpdesk in the past has been
>handling an overwhelming load of calls at the start of past semesters of
>people needing assistance with passwords for various systems, and getting
>logged in to these systems. In many cases, the passwords and usernames
>have been different, or the way that one needed to sign-in differed. This
>causes a lot of documented confusion on the part of users as evidenced by
>our help desk ticket history.

Sure, but that's demonstrating the need for simplified sign-on, not single.

>Well, I don't know the answer to this question either. From my limited
>understanding of SLO issues, I would wonder if there were some sort of
>server based / query string / unique identifier / stored database
>solution that could preempt the need for third party cookies all together.

It's implementation specific. If you're asking whether my SP could pull
this off, the answer is yes, if I take out the requirement that the front
channel logout of a session actually be accompanied by the cookie for that
session. I've leaned toward doing that, and just assuming that requiring
the message be signed is enough to prevent people logging off others'
sessions.

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?

But many SAML implementations are client-side state only and won't even
store the logout to check against later when the user comes back to use
the session. And of course SAML doesn't say anything about it being
required to implement all this in a manner that doesn't require third
party cookies.

And then you have all the apps doing their own sessions that can't be
cleared via a back channel.

So it becomes a question of scope. Produce a viable solution for
Shibboleth only deploys with particular session assumptions, or worry
about the larger implications.

As a practical matter, it's also the case that in any medium term, every
SAML logout you do will be partial, since you won't see mass adoption of
the capability. Can we explain that to users? And even if we could, isn't
the explanation simply that the behavior your people are up in arms about
is in fact the reality? "We have good news and bad newsŠhere's the bad
news..Sorry, we lied about the good news."

>What I don't know is whether or not third party cookies are the only way
>to fulfill SLO requirements. Could there be a solution that hasn't yet
>been fully explored? It seems that such a solution one, if it exists,
>would make SSO so much more beneficial in comparison with its negatives -
>which would make its value rise exponentially, I would think.

See above. You can do it, but there are constraints. So far we have felt
the constraints are enough to sink it, but we have also said that we would
probably implement the back channel from the IdP at some point because it
is easy to do, and it doesn't have the same flaws.

It's just a priority thing at this point. I actually had expected the SP
work to die down and was expecting to hack out SOAP SLO into the IdP this
year, but there was too much for me to do on my end.

-- Scott