IdpSession Logout Problems

[Skylar Hansen]

Hi Scott,

When you asked:

<<"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?">>

That is an excellent question, and a solution that I'm considering currently. I can see problems occurring with users' failure to understand that logging out of the portal does not equate to logging out of all of the items that are available IN the portal. 

For example - if the user is on the portal, accesses Moodle from their portal page, and clicks the portal logout then the user may expect that Moodle is logged out too. Our Moodle allows users to stay logged in for several hours and this requirement cannot change. Otherwise, students would possibly lose post data if they timed out in the middle of writing a very long journal entry, forum post, or survey. 

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.

On the other hand, users would get the temporary satisfaction of not being able to go "around the loop" and get right back into the portal that they just logged out of. I don't like security through obscurity and I prefer to never give people a false message from a UI. BUT, logout is a feature that they are demanding very loudly. 

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 don't ultimately know the answer there.

<<" If people see it as having little benefit, then maybe you have a community that doesn't value SSO.">>

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.

 << 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).>>

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.

<<" 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.">>

I am someone who thinks that third party cookies *should* be blocked more frequently. The potential for exploitation is there, and it is more dangerous than I think many people realize. Whether it will actually happen is another matter, but I do agree with you that it is best not to depend on third party cookies to accomplish SLO or anything else.

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.

Others have implemented "pretty good" solutions which seem to appease users need to logout. I think that I am going to have to find one of those "pretty good" solutions, and make it difficult for users to find the flaws. That will require a great deal of custom scripting and adding of common features on systems that in many cases are closed source, not supported, etc. 

I've thought about doing some browser sniffing on the Idp login page, and blocking Firefox users with these session persistence settings from logging in - but that would be a Band-Aid and a maintenance nightmare. It would also go against our philosophy that users are allowed to access our systems with whatever device / browser / system they choose (however misguided)

Your suggestion to redirect to an Idp page that kills the cookies seems most sane at this point. Thanks for that, and your very thoughtful reply.

Best,

Skylar


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, October 28, 2011 11:42 AM
To: users at shibboleth.net
Subject: Re: IdpSession Logout Problems

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

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net