* Peter Gietz peter.gietz@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