IdpSession Logout Problems
Skylar Hansen
Hello,
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.
Our helpdesk recently found that when Firefox is set to save the last session, that users are also not being logged out of Shibboleth even if the browser window HAS been completely closed. So, if a student logs off of our portal on Firefox having been using one of our student lounge computers, and another student comes in behind them within the 20 minute window, then the next student could be logged in as the previous student. This could result in extremely serious privacy concerns and according to management - possible violation of FERPA laws. According to Firefox documentation, this is not a default setting, but our help desk manager is convinced that this is the default behavior.
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. Tensions are very high, and people are panicking about Shibboleth. It is seen as a huge security hole with little benefit.
I am having an extremely difficult time helping my colleagues understand that the purpose of Shibboleth is sign IN not sign OUT, and that the main purpose of a portal is integration / interoperability. Having SSO is a huge part of this, and a huge convenience to users who will very quickly choose not to use resources that prove too cumbersome, annoying, or difficult – which signing in over and over again certainly is.
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.
Does anyone else have a similar story, lessons learned, or possible solutions? Any advice would be very much appreciated.
Regards,
Skylar
Paul Hethmon
Reply-To: Shibboleth Users <us...@shibboleth.net>
Date: Fri, 28 Oct 2011 10:52:15 -0400
To: Shibboleth Users <us...@shibboleth.net>
Subject: IdpSession Logout Problems
Hello,
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.
Our helpdesk recently found that when Firefox is set to save the last session, that users are also not being logged out of Shibboleth even if the browser window HAS been completely closed. So, if a student logs off of our portal on Firefox having been using one of our student lounge computers, and another student comes in behind them within the 20 minute window, then the next student could be logged in as the previous student. This could result in extremely serious privacy concerns and according to management - possible violation of FERPA laws. According to Firefox documentation, this is not a default setting, but our help desk manager is convinced that this is the default behavior.
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. Tensions are very high, and people are panicking about Shibboleth. It is seen as a huge security hole with little benefit.
I am having an extremely difficult time helping my colleagues understand that the purpose of Shibboleth is sign IN not sign OUT, and that the main purpose of a portal is integration / interoperability. Having SSO is a huge part of this, and a huge convenience to users who will very quickly choose not to use resources that prove too cumbersome, annoying, ordifficult – which signing in over and over again certainly is.
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.
Does anyone else have a similar story, lessons learned, or possible solutions? Any advice would be very much appreciated.
Regards,
Skylar
Chad La Joie
<sha...@randolphcollege.edu> wrote:
> Our helpdesk recently found that when Firefox is set to save the last
> session, that users are also not being logged out of Shibboleth even if the
> browser window HAS been completely closed. So, if a student logs off of our
> portal on Firefox having been using one of our student lounge computers, and
> another student comes in behind them within the 20 minute window, then the
> next student could be logged in as the previous student. This could result
> in extremely serious privacy concerns and according to management - possible
> violation of FERPA laws. According to Firefox documentation, this is not a
> default setting, but our help desk manager is convinced that this is the
> default behavior.
Yeah, it's the default behavior now. Web browser vendors have stated
numerous times that they do not view cookies as a security mechanism,
so there is no problem with keep "session" cookies around
indefinitely. Not much we can do about that, we've tried.
> 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. Tensions are very high, and people are
> panicking about Shibboleth. It is seen as a huge security hole with little
> benefit.
Then, as Paul said, disable SSO. Or install the Hungarian SLO
extension, give people what they want and really open up a security
and usability nightmare.
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Cantor, Scott
>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
Brent Putman
On 10/28/11 11:41 AM, Cantor, Scott wrote:
>
>> 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.
>
I was actually looking at this earlier this week to find out the current
state of things, since we've had some mild grumblings here about logout
and the lack thereof. To add some detail to this:
>From what I learned, some of it from reading some Mozilla bugzilla items
about it, this session persistence behavior is associated specifically
with the browser startup option "Show my windows and tabs from last
time". Changing that to one of the other options should disable the
session persistence. I did test this with FF 7.0.1. This seems like a
viable option if you can lock down and control the machine, such as in a
lab or kiosk environment.
Scott, are you saying that the "show windows/tabs from last time" option
is the installation default now and/or on recent versions? I didn't
find anything about that and I don't have a fresh machine on which to
test...
Further, and perhaps more importantly, if this option is enabled: the
session cookies that it keeps around are tied to specific tabs. So
closing the tab (or all tabs if multiple) that were associated with the
session will result in the session cookies for that tab(s) being thrown
away, and they are not there when the browser is shutdown and restarted.
I did also test that this basically works with FF 7.0.1 (although I
can't attest to all the possible modalities, etc). It occurred to me
that if there is a way to have some (user agent-specific) client-side
Javascript via a button or link that caused all the tabs to be closed
before closing the browser, that might actually be a possible workaround
for this issue, e.g. have the app logout process return a page that says
"Click this button to close the browser and complete the logout
process". I don't know enough client-side JavaScript to know whether
this is possible or not. Does anyone?
Skylar Hansen
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
Cantor, Scott
>Scott, are you saying that the "show windows/tabs from last time" option
>is the installation default now and/or on recent versions? I didn't
>find anything about that and I don't have a fresh machine on which to
>test...
No, I think you're right and I misspoke. The restore option I don't think
is the default, it's just that the cookie thing is definitely done if you
set that option. I thought that there was a setting to control the cookie
behavior when that option is set, which is what I was referring to.
>Further, and perhaps more importantly, if this option is enabled: the
>session cookies that it keeps around are tied to specific tabs. So
>closing the tab (or all tabs if multiple) that were associated with the
>session will result in the session cookies for that tab(s) being thrown
>away, and they are not there when the browser is shutdown and restarted.
That's very likely true. It isn't that they go away when you close the tab
itself, but the tab not being part of the restore set if you close down
means the cookies also aren't.
-- Scott
Cantor, Scott
>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.
Skylar Hansen
http://kb.mozillazine.org/User:Dickvl/Private_Browsing_disable
(Changing the about:config setting privacy.clearonshutdown.sessions)
-----Original Message-----
From: users-...@shibboleth.net [mailto:users-...@shibboleth.net]
On Behalf Of Brent Putman
Sent: Friday, October 28, 2011 2:19 PM
To: us...@shibboleth.net
Subject: Re: IdpSession Logout Problems
Cantor, Scott
>I might try something like this:
>
>http://kb.mozillazine.org/User:Dickvl/Private_Browsing_disable
>
>(Changing the about:config setting privacy.clearonshutdown.sessions)
Right, but is the context/goal to deal with managed machines, or machines
in general?
One of the options discussed has been using custom login handler code to
support opting out of SSO at the login page, to let people self-select
that they're on a shared box.
Obviously that puts onus on the user, but it does provide some degree of
SSO without totally ignoring the problem.
-- Scott
Peter Schober
> At my organization we recently went live with a Shibbolized portal and
> we are having some severe issues with users being able to logout.
While nothing I write below is new or will help with people screaming
at you and demanding the IdP admin's head on a plate, I do think it's
necessary to look at the percieved problem space in more detail.
Logout is not an end in itself, even if it's sometimes presented that
way, e.g. in your android phone story below.
Logout usually is (a) a means to prevent unauthorized access to your
account and your (and possibly other's) data. And (b) it's sometimes
used to implement account switching (e.g. to check the LMS with
student vs. teaching assistent permissions).
The former case is what we're usually talking about here, the latter
often is the consequence of having to use lesser software (that
doesn't provide such a functionality on its own) or of an
institutional tradition of handing out one account per
role/affiliation one has at the instition, creating the problem of
account switching in the first place (also owing to insufficient IdM &
access management practices, of course).
People working in offices, on their individual PCs, laptops or
workstations have several other ways to protect their webbrowser:
First there's physical security, i.e., doors with locks on them.
And since active web sessions are by no means the only threat, the
desktop and all its data and applications will need to be protected
anyway, so at least locking the screen (manually when leaving,
automatically from a "screensaver") is inevitable anyway. Doubly so in
shared office spaces.
No need for Web SLO there, and it wouldn't be sufficient.
> 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.
Why should I want logout from a web application from my personal phone
(or notebook or netbook or workstation)? The device itself needs to be
protected with a password, passphrase, guesture, PIN, fingerprint,
iris scan or what have you. And physical security, again, since you
don't want it stolen either.
[ I do find it highly ironic that now "logout" comes back as
"conventional wisdom" as a demand from users and business people to
security staff. Possibly paraphrasing Scott: "We can't be bothered
with reality, just give us a logout link. You said to always logout
yourself!" ]
So IMHO that leaves only two legitimate scenarios where logout
might become a problem:
* Public shared computers -- your student lounge, library, PC lab, all
of which you can control/influence in some way in your own
institution, by educating the people running things (or getting
policies created and enforced) to configure the thing safely (i.e, not
using FF's b0rken session restore, allowing the browser/desktop to be
exited completely).
Of course then there are all the other public computers you have no
way of controlling, in the worst case some shady internet cafe while
you're on holidays. But in almost all of these places my concern would
be bigger to have my credentials themselfs "logged"/copied directly
from the desktop than someone reusing a leftover session when I walk
away. Also since you often pay for these services the desktop and
browser sessions usually expire when your session expires.
If in doubt, don't use the system at all.
Also with netbooks and other personal mobile devices, GSM/3G roaming,
phonecards, open/free fireless networks, etc. people depend less on
the PC infrastructure in such internet cafes/call shops, meaning fewer
shared public computers (I think). Which leaves us with...
* Account switching. Might not be a problem at your institution. I've
been told it's a problem in ours and for the moment I insist on this
being an application (integration) problem. Implementing "Act as..."
in every application that needs this is of course lots of redundant
work (if you can change the app at all, less so today with SaaS/ASPs),
requires some IdM/AM infrastructure (who may proxy for whom) and
pushing the feature request to the WebSSO system is an easy way out.
In the days of local authentication at each resouce logout + login
with some other account was easy (if less than elegant/desirable), SSO
only made the problem appearent.
I'm not convinced that anything one comes up to deal with this
(e.g. mandate single/global logout or do away with standards-based
identity federation!) beats using another browser (or another
instance of the same browser), in any respect. The number of people
who routinely need this is limited and the number of accounts these
people want/need to use is limited as well (so we're not talking about
juggling 13 different browser instances).
Note that at the same time there's a demand for desktop SSO (cf. the
recent SPNEGO thread), which I image would make any kind of logout
even more fun (but then locking the desktop alone works today, without
SLO). Looking forward to people recommending complete logout from the
desktop to change the account used on an arbitrary web page on campus.
But no, those other accounts are not permitted to login to your
managed PC... we're back to "use another browser" (one not properly
configured for SPNEGO)? ;)
-peter
Kristof Bajnok
> 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
* back-channel authentication
* outgoing TCP might not be allowed by some IdP cluster setups
(firewalls or load balancers)
* 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)
For the OP: more SLO issues:
https://fed-lab.org/best-practises/single-logout/
;)
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.
Kristof
Cantor, Scott
>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
Christopher Bongaarts
> On 10/28/11 2:28 PM, "Skylar Hansen"<sha...@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.
FWIW, the requirement we have heard loud and clear is simple: "screw
the other apps, I need a way to make it so the user can 'log out' such
that they have to reauthenticate to get into MY app". This is a natural
result of having application responsibility spread among multiple people
(more cynically, it's multiple instances of CYA).
So we had to implement the IdP session killing technique on our own,
which is not elegant but does have the advantage of being understandable
to users (you can have them land on a page that says "you just logged
out of X, but you may still be logged in to lots of other things." (We
also, as a short term fix, shortened our session lifetime to 5 minutes
for our current system that uses our local SSO system for login - apps
can have the user log out of our local SSO, which uses a shared cookie
mechanism so SLO is actually useful, but the IdP session was still
catching them).
For the public terminal case, this actually devolves into the "user
switching" problem - 99% of the time, User B doesn't care about messing
with User A's still-logged-in session, B just wants to register for
their classes or whatever. And they can't if there's no way to switch
users.
--
%% Christopher A. Bongaarts %% c...@umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
Chad La Joie
owner what should happen.
I wish we had access to an actual user-experience/interaction group so
we could get further on this problem. But so far, that hasn't
happened.
On Tue, Nov 1, 2011 at 11:02, Christopher Bongaarts <c...@umn.edu> wrote:
> FWIW, the requirement we have heard loud and clear is simple: "screw
> the other apps, I need a way to make it so the user can 'log out' such
> that they have to reauthenticate to get into MY app". This is a natural
> result of having application responsibility spread among multiple people
> (more cynically, it's multiple instances of CYA).
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Skylar Hansen
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.
It would be great if it were possible to keep track of which SP's
contacted / logged in to / out of the Idp per user and when in a query
able (perhaps database or xml) format. I would want to store records of
the user name, user agent, IP address, SP connection date/time,
connection expiration date/time, etc along with the session ID and some
kind of status code (connected, disconnected, attempting logout,
attempting login, unknown, etc.)
I haven't thought all of this through, but it would makes sense to me if
the SP could do a double check for a valid Idp session in the Idp
session database periodically and then, if there isn't a valid Idp
session found it would update the session records and attempt to logout.
Something along these lines, I would think, would allow for a more
complete logout even if someone had signed in on multiple browsers. The
UI could at least report an accurate status of complete or partial
logout.
<<And then you have all the apps doing their own sessions that can't be
<<cleared via a back channel.
You could argue that if it isn't a Shibboleth app, then it is beyond the
scope of Shibboleth. I think most people would understand that.
<<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?
It seems that avoiding ambiguity with users works best when possible. My
management actually insisted that I NEVER tell users about Shibboleth.
He doesn't even want to hear the word outside of our office.
I implemented a solution that seems to have satisfied our users for the
moment. In order to get it to prevent people from going into their web
histories and clicking on pages that haven't logged out, I wrapped some
of the external apps inside framed portal pages. This is definitely an
illusion more than anything.
I also have the portal doing a bunch of logouts from a custom portal
logout page. When those are done, the portal redirects to a custom
logout.jsp page on the Shibboleth Idp that deletes the Shibboleth
_idp_session and Shibboleth JSESSIONID cookies, and then invalidates the
session.
This solution prevents people from "going around the loop" and getting
right back into the portal that they just signed out of, and seems to
have calmed the storm for now.
(Thanks again Ken and Dan :)
Cantor, Scott
>
>I haven't thought all of this through, but it would makes sense to me if
>the SP could do a double check for a valid Idp session in the Idp
>session database periodically and then, if there isn't a valid Idp
>session found it would update the session records and attempt to logout.
I don't think it's easier to invent a new protocol for tying sessions
together and add a database to the IdP than to just change the SP to track
logout requests independently of a cookie showing up.
>Something along these lines, I would think, would allow for a more
>complete logout even if someone had signed in on multiple browsers.
I don't think it's our intent to treat multiple browser sessions as
related unless the SAML logout features for doing that are used.
> The UI could at least report an accurate status of complete or partial
>logout.
The point is whether it helps if the answer is always partial. And what
does that mean? It's circular. If you can't logout any other way, then
you're being told "you're screwed". If you can, then you didn't need the
logout protocol.
>You could argue that if it isn't a Shibboleth app, then it is beyond the
>scope of Shibboleth. I think most people would understand that.
There really aren't many Shibboleth apps. Most apps do their own sessions,
so by that definition, it would rarely if ever apply.
>It seems that avoiding ambiguity with users works best when possible. My
>management actually insisted that I NEVER tell users about Shibboleth.
>He doesn't even want to hear the word outside of our office.
I don't blame him. But if the common case is ambiguous, you're kind of
stuck.
>I also have the portal doing a bunch of logouts from a custom portal
>logout page. When those are done, the portal redirects to a custom
>logout.jsp page on the Shibboleth Idp that deletes the Shibboleth
>_idp_session and Shibboleth JSESSIONID cookies, and then invalidates the
>session.
Just FYI, there is no JSESSIONID cookie involved at the IdP unless you
added something that's using it.
-- Scott