Am 19.03.2019 um 14:09 schrieb Peter Schober:
- 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:
And thanks for these:
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.)
I know, but it is a common fear in the library community and we should therefore address such fears. And yes: a lot of SAML implementations especially on the SP side are suboptimal.
For three reasons:
- 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.
I think that is what she meant. It is not transparent to the uneducated user, that the IdP sends her data to any SP, she connects to. One task of FIM4L will be to make all this transparent to the libraries and their job will be to educate their users accordingly.
And very likely (for those enjoying GDPR protection) the subject will have been informed about any data for transparency reasons even before that.
Well, we will definitely recommend consent at IdP. Anything else would be (hidden) in terms of use and not read by the user.
- 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.
Yes, no doubt here, but again: we need to address this in a very non-technical way. The IP-Address will still be an identifier, but that is of course also the case in IP-based authentication.
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).
Yes that is why we will recommend eduPersonTargetedID and/or pairwise SubjectID instead of IDs that are the same for every SP.
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.
- 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!
Yes all you say is right and isn't challanged by this group. I quoted the library professor to make aware of the mindset of the libraries.
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.
Well that is the current real life experience of the users and they therefore fear that the usage of similar technologies will result in similar issues. And some of these fears might not be too stupid:
Google, FB and the kind live on collecting behavioural data of users, and technologies that we also use, help them doing that. The fear is, that publishers now also want to collect such data and not only for providing services like "users who read this article also read that article"
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.
Yes. But you see that she did understand the difference between Google and our federations.
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.
Right, but that is a real life example and such influence the mind sets. And there are several reasons why they are doing it wrong, and they are in this case the publishers.
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.
To make it very clear: FIM4L wants to promote the usage of FIM. In AARC 1 we made the experience that libraries seem to be very reluctant to switch to it and FIM4L wants to analyse why and find a better way to convince. That is why I posted the quotes of that article. And what we two are doing now, is to analyse and find a better way to convince.
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).
Fine then we are in agreement here as well. And that is what I intended with my post: Reuse the recommendations of librarians may be also quoting them to make clear that FIM4L is taking the side of the libraries, and from this we can also make clear that e.g. the technical proposals of RA21 are ok to follow, but in general the usage of the technologies should be done carefully with highest privacy protection as possible.
Thus I think, we are in agreement on this.
Cheers, Peter G.
- 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 _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l