[Fim4l] Stanfords statement

Peter Schober peter.schober at univie.ac.at
Tue Mar 19 14:09:16 CET 2019


* Peter Gietz <peter.gietz at daasi.de> [2019-03-19 13:31]:
> Here you find good counter arguments against SSO which we should address
> (basically the same I learned then in Berlin). Since it is a quite long
> text, I am quoting the IMO most relevant passages here:

Thanks for summarizing, a few comments:

> > Here’s my understanding. When fully realized, it means that by logging
> > in once, you would be recognized on all participating platforms, which
> > means you could leave a data trail of both who you are and what
> > resources (content and tools) you are using. Yes, that means your data
> > could be potentially aggregated across platforms and combined with other
> > datasets to create a more complete profile of you as a user.

That's both an oversimplification and a bit of a strawman argument in
that this is obviously not how federated authentication systems were
designed to work. (It may well be how some broken deployments do in
fact work, though.)

For three reasons:

1. With one authentication I won't be logged in (and therefore
"recognized") "on all participating platforms": Data about me (however
much or little) only reaches the "participating platforms" if and when
I decide to actually access their resource and chose to log in.  And
very likely (for those enjoying GDPR protection) the subject will have
been informed about any data for transparency reasons even before
that.

2. The above assumes that a stable identifier for a subject will
always be available (which is not the recommended and not the current
model, where only the non-PII "common-lib-terms" eduPersonEntitlement
attribute value or alternatively an aggreed-upon
eduPerson(Scoped)Affiliation attribute value would suffice to
authorize the subject). I.e., there may not be any identifier specific
to the subject.
2.1 Even in case a stable identifier is in fact required by the SP
there's no reason the IDP should send all SPs the same (shared)
identifier value as any other SP. We had the eduPersonTargetedID for
that in the past, the proper SAML 2.0 persistent NameID in the
not-so-distand past and the pairwise-id from the new SAML SubjectID
Attribute Profiles specification today and in the future (as long as
SAML remains relevant).
So "service-specific pseudonyms" (as WAYF.dk phrased those
identifiers) have existed all along and have been invented by the same
people and at the same time Shibboleth was invented in order to
provide location-independent access to institutionally licensed resources.

3. Due to 1 there is no univeral state of "being recognized
everywhere" and due to 2/2.1 there's no way for different SPs to
collude behind the back of the subject to create profiles of the
content accessed -- at least no way that wouldn't be there without
federated identity management, too!

> > It is likely that you are already leaving trails of use data
> > connected to the IP addresses of the devices that you use. With
> > federated identity, the trail is connected to you and to the
> > devices. An analogy is how one can use a Google login to access
> > not only your Gmail but also Dropbox, Asana, etc., and then Google
> > is able to build a profile of you as a user by integrating the
> > data from your activities across platforms and tools.

That's precisely what multi-party federation is NOT. The above is the
result of having a single IDP in the world, and one able to dictate
whatever behaviour it wants from all SPs conntected to it.
That's not an analogy, that's the antonym.

> > A side note here: I acknowledge that the SAML approach embraced by
> > RA21 is more privacy-protecting than, for example, adopting a
> > Google or Facebook OpenID option. It is not, however, more
> > privacy-protecting than IP authentication.

When done properly (as thousands of institutions have been doing for
well over a decade) it is also not *less* privacy-protecting than IP
authentication, which should be added for fairness of the argument.

> > I recently watched as a campus technology SAML/Shibboleth system
> > passed a user’s email address, full name, and staff/staff status
> > to a vendor in order to allow access to a PDF from off-campus when
> > on-campus access would have been possible based on IP address
> > alone.

They're Doing It Wrong. As simple as that.

The anecdotal evidence that such things happen may be indicative of
many things (e.g. that Federation is too complicated to grasp) but it
does not invalidate the approach of federated identity management.

> At the end, she makes a number of recommendations, that IMO more or
> less should also be included in our guidelines:

Contrary to the arguments presented so far in the summary those are
all easy enough to agree with.
(Of course talking to "InCommon ... about privacy" is the very
definition of what US-Americans call "preaching to the choir", but it
wouldn't do any damage either).

> >   * Regularly use library resources without using IP address
> >     authentication to monitor the user experience of identity-based
> >     authentication and the messaging from platforms to users. [..]

Both IP-based access (in the "off-campus" case) as well as federated
authentication come with major UX issues. It's simply a trade-off or a
personal preference. There is no clear advantage even UX-wise for
either method (again, including the "off-campus" usage pattern).
(I don't feel that's the heart of the topic so I won't go into detail
here now.)

-peter



More information about the FIM4L mailing list