Shibboleth Developers

["Scott Cantor" <>]

Peter Schober wrote on 2009-07-15:
> Well, with many people seemingly unable to tell the difference between
> a webbrowser and a local filemanager (a distinction being blurred
> purposely for certain reasons), or more to the point, between closing
> a browser window and exiting the program/process, I'd say closing the
> webbrowser to log off doesn't work too well either.

I think what ultimately doesn't work well is making people non-responsible
for the theft of their identity. It's a political problem that people suffer
few if any professional consequences (speaking of employees here), and I
don't think there's a technical solution to that.

I don't know what to say about personal access, because if somebody is lazy
about things and walks away, I don't see why it's deserving of sympathy if
something bad happens.

But however well it works now, I don't think the incidence of problems will
decrease with a protocol.
 
> But could you elaborate on the rest of that statement above?

I'm saying I don't think shared machines should be operating with SSO. If I
thought I needed to do something, I would do location-based checks to bypass
SSO for them, and combine that with very short timeouts so that walking away
results in a quick loss of access.

It doesn't even require explicit protocol support, since it's a function of
authentication and the IdP's choices about session management.

But would I personally advocate for that? Only for locked down kiosks
without the ability for users to deal with the problem. For shared machines,
I don't see how anything is ever going to work better than making users
responsible.
 
> Managers just smile at us and walk away when we mention
> integration of their business application with the campus WebSSO system,
> but need to tell them Sorry, Logout will only come in later releases
> (2.0, judging from some Internet2 presentations -- which btw also helped
> selling Shib as intra-campus WebSSO system in the first place).

I'm not going to apologize for something I didn't promise, but I haven't had
a system that supported logout in maybe 13 years of writing and deploying
them, so the idea that I would advocate for anything based on that is just
incorrect. I considered it viable without logout, and still do.

What I find causes the most problems are the fact that people leave
applications to expose bogus logout links and don't take care to disable
them or block them.

> Certainly some kind of risk assessment (however basic) would help to
> rationalize some of those arguments and discussions. But we're still
> having a hard time with application integration and having to resort to
> disabling SSO won't help: Those concerned about their app security still
> won't integrate (unless timeouts are so small it will make the app
> unusable), those wanting to join because of SSO won't get it.

I'm not arguing about what others are dealing with, that simply hasn't been
my experience, and my opinions are shaped by that.

I'm NOT saying I don't get asked about it. Of course I do. And I tell them,
no, it's not supported. Then I ask a few questions about how they think it
would work, they get really confused very quickly and decide that it
wouldn't fly anyway, and at the end of the day, they don't give up SSO or
integrating with the enterprise just because of logout. I can think of one
case where that happened, and it was a political/personality thing, not a
technical or security issue.

> Either way, I'm grateful that Adam started working on this, even if
> there seem to be strong opinions wrt the futility of the endeavor.

Well, I think it's worse than that, I think it's a trap. Other systems
coming down the road do not support logout. I don't think that's going to
change because the future is to build more into the client (thus making it
explicit that it's a client problem to deal with). Deploying a capability
now that will disappear later strikes me as a bad thing. In some ways, it
could actually be more of a problem if it *did* work.

> I do think we need practical experience with SLO, time to adapt our
> applications, maybe switch to ePTId/persistentIds as NameIDs whereever
> possible/sensible (to ease logout for both IdPs as well as SPs), etc.

Not sure I follow that last part.

-- Scott