Shibboleth Developers

[Peter Schober <>]

* Scott Cantor 
<>
 [2009-07-15 23:13]:
> 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.

ACK. The more reason to try what we can to offer ways to end a
session, SLO being part of it. If they still just walk away they only
have to blame themselfs (and we will spell that out to our users).

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

ACK. But from the above I don't think it's configurable to do this
with the released IdP right now, is it?

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

No need to apologize for anything. It's just that for us logout was
always part of the system, and waiting for 2.0 didn't seem so bad
(since we then only had to run a single system, as compared to a
campus SSO system with logout -- e.g. Cosign -- tied to the IdP;
what we had piloted with the 1.3 IdP).

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

ACK.

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

May hint to risk assessment and to "rationalize" things was meant to
say that there are certainly non-technical aspects to this, but
*sometimes* a technical answer is just as effective. Never mind, I
just wanted to put things in context.

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

That's certainly a new perspective, so I'm glad I wrote the
above. Like I said before: there seem to be quite a few more reasons
why the project is "cautious" (to say the least) to go forward with
SLO, and most of them are not documented anywhere.

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

From what Adam wrote (one the IdP session expires the IdP loses the
ability to sent back-channel SLO messages to utilized SPs whose
session outlived the IdPs session) I thought if the IdP and SPs had a
stable identifier for a principal a few of the problems related to
back-channel SLO would be resolved easily: the IdP doesn't need to
store session indices or transientIds or anything else with the
session (or even longer than the session, see above). Neither does the
SP, they just rely on the ePTId-NameID as a primary key to end
someones session.
Of course transients have an additional privacy-preserving feature
that by themselfs I cannot re-identiy a returning user, but I suppose
in many cases there will be (additional) attributes released that will
identify a user anyway, some of the might even the the ePTId.
-peter