IdpSession Logout Problems

[Cantor, Scott]

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

>At my organization we recently went live with a Shibbolized
>portal and we are having some severe issues with users being able to
>logout. We
>have the Idp session set to expire after 20 minutes. The portal has a
>logout
>button, but if one does not close the browser window completely,
>including all
>tabs, and any processes open, then when one clicks back on the portal
>w/in the
>20 minute window, they are instantly re-logged in via Shibboleth.

What would happen if you linked the portal's logout button to a redirect
to the IdP server to a script that cleared its cookies? Would the fact
that the user is still logged into other SPs matter enough, or would you
buy credibility even if it's mostly a technical illusion?

> 
> 
>According to Firefox documentation, this is not a
>default setting, but our help desk manager is convinced that this is the
>default behavior.

It is the default. Firefox used to save only non-secure cookies when it
did that, but they broke the feature by keeping all cookies in, I believe,
FF 4. Possibly earlier, but around then.

>Another person logged in to our portal via her android
>phone, and then clicked logoff, but found that she was able to get right
>back
>into her email. She told me that she feels that the IT department has no
>credibility if she cannot logout of her email.

I have noted that if you don't actually implement logout, you're doing a
bad thing by leaving application logout buttons in the UI. That's simply
wrong IMHO.

> Tensions are very high, and
>people are panicking about Shibboleth. It is seen as a huge security hole
>with
>little benefit.

If people see it as having little benefit, then maybe you have a community
that doesn't value SSO. At my university, one of the reasons we really
need it is that we're so decentralized that often a single business
process requires accessing multiple discrete systems. Without SSO, it
would get very cumbersome for users. We have no portal, for example. Often
a portal is a substitute for doing SSO since you access things via the
portal rather than by hitting different servers.

> 
>I¹ve read numerous threads discussing these issues,
>and have shared the recommendation that SLO is not recommended, and a
>virtually
>untenable solution. However, this has gone over like a lead balloon. My
>management is about to have me remove Shibboleth from our organization all
>together.

My only response is: tell me why I'm wrong about logout. I know one school
of thought is that people like me that don't allow third party cookies are
too much a minority to care about, so front channel logout works fine for
the vast majority (if you ignore SAML 1.1 support at least).

I happen to think that over time, the privacy arguments we see going on
are going to result in more movement away from third party cookies or at
least wider use of tools to block them. If that is the case, do we want to
be deploying a solution that will completely break when it does? That's my
argument, anyway.

-- Scott