"Password leak at Elsevier"

Peter Schober peter.schober at univie.ac.at
Mon Apr 1 14:34:59 EDT 2019


* Jorj Bauer <jorj at temple.edu> [2019-04-01 18:43]:
> Fundamentally, we rely on InCommon to identify "bad actors" and
> prevent them from joining the federation, so we can use membership
> in the federation as a mitigating control against bad actors, so
> that we don't release information about people to bad actors.

I highly doubt there can be any formalized process -- business or
technical that would ensure a membership 100% free of "bad actors".
And that's even before going into what "bad actors" are in your
opinion (vs. someone else's).
Rely on what the federation promises to provide you with, but nothing
more.

> From a technology perspective, this feels like a very nascent (or
> perhaps just naive) approach to attribute release.

It's not a good approach, agreed. Therfore it hasn't been recommended
(or actively discouraged) by/in this communtity for years.

(Never mind some federations still propagating a model where the fact
that some random company managed to sign an agreement to join the
federation is seen as sufficient to provide them with a wish list of
attributes to pick from, uncurated/unreviewedd by the federation
operator.)

Again, only rely on those checks to be performed that the registrar /
federation operator promises to perform.

> Consent-based release is a good try, where I worry users just don't
> have the understanding to do the right thing - and therefore (in my
> eyes) it falls short.

Not many federations have been pushing conent as the prime model for
attribute release for the reason above (and because of hard to
detect/control -- often contextual -- fringe cases where consent isn't
freely given and so would be invalid anyway).
In our own documenation it's mentioned as a last resort:
https://wiki.univie.ac.at/display/federation/IDP+3+Attribute+release

To me it's clearly the better alternative allowing the subject to
access desired services at their own risk (taking on responsibilty for
the attribute release via demonstratedly consenting to the release)
than for the organization to not release anything to anyone out of
fear of litigation (or whatever).

> I'm not sure what the step beyond that would be that would give us
> adequate controls, from a technology/usability/policy perspective. I
> haven't spent a lot of time dedicated to thinking about it either...

Others have, luckily. Entity categories (REFEDS R&S, GEANT CoCo for
those also having to deal with European cooperation partners) are one
of those things meant to enable scalable *and* controlled attribute
release.

> From an administrative perspective, I'm concerned about "bad actor
> acquires formerly good actor that's already in the federation."

Sure. E.g. video2brain joined our federation, was later acquired by
lynda.com, which was later acquired by LinkedIn, which was later
acquired by Microsoft. It won't be a surprise to anyone here to hear
that federated logins do not work anymore.
(At which point they removed the multi-party federation capabilities
of the system I don't recall.)

-peter


More information about the users mailing list