Hi all,
For your interest: "Protecting Patron Privacy in Digital Resourceshttps://scholarlykitchen.sspnet.org/2019/03/13/guest-post-protecting-patron-privacy-in-digital-resources/?utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+ScholarlyKitchen+%28The+Scholarly+Kitchen%29" on Scholarly Kitchen.
Stanford library made a statementhttps://library.stanford.edu/using/special-policies/statement-patron-privacy-and-database-access recently about patrons privacy. I think this statement perfectly aligns with our work.
It draws the libraries' concerns and underlines the importance of our work. FIM4L should have the ability to make e-resource access with SSO better than using IP based access. Libraries cannot win the fight for preserving patron privacy by keep using IP based access.
I think we even have to encourage SSO access (when Open Access without authentication is not possible) in order to "... carefully structure [SSO access] to minimize exposure of patron data as much as possible, but always to ensure disclosure of any PII that may be transmitted." According to the article.
all the best, Jos
Jos Westerbeke Library IT Specialist / Demandmanager | Erasmus University Rotterdam, Library | Burgemeester Oudlaan 50 | 3062PA Rotterdam | jos.westerbeke@eur.nlmailto:jos.westerbeke@eur.nl | +31 640295513
Hi,
thanks a lot, Jos, links to the documents added at Background chapter at FIM4L Guidelines and recommendations draft.
All the best
Jiri
On Fri, Mar 15, 2019 at 10:03 AM Jos Westerbeke jos.westerbeke@eur.nl wrote:
Hi all,
For your interest: "Protecting Patron Privacy in Digital Resources" on Scholarly Kitchen.
Stanford library made a statement recently about patrons privacy. I think this statement perfectly aligns with our work.
It draws the libraries' concerns and underlines the importance of our work. FIM4L should have the ability to make e-resource access with SSO better than using IP based access. Libraries cannot win the fight for preserving patron privacy by keep using IP based access.
I think we even have to encourage SSO access (when Open Access without authentication is not possible) in order to "... carefully structure [SSO access] to minimize exposure of patron data as much as possible, but always to ensure disclosure of any PII that may be transmitted." According to the article.
all the best,
Jos
Jos Westerbeke
Library IT Specialist / Demandmanager | Erasmus University Rotterdam, Library | Burgemeester Oudlaan 50 | 3062PA Rotterdam | jos.westerbeke@eur.nl | +31 640295513
Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Jos, hi all,
this is definitely interesting reading. Even more interesting IMHO is an article referenced there: https://scholarlykitchen.sspnet.org/2018/01/16/what-will-you-do-when-they-co... , a blog post by Lisa Janicke Hinchliffe, Professor/Coordinator for Information Literacy Services.
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:
Federated Identity (and Privacy)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. 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.
Such federated tracking is unlikely to be fully developed in the initial RA21 projects and the most pernicious form would require publishers to collaborate in data sharing in ways that they currently are not inclined to do. But, I think there is every reason to anticipate such technologies could be created in a fairly short period of time should those sentiments shift.
and a little later:
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.
[...]
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.
[..] publishers and platforms will likely prefer identity-based authentication mechanisms [..] I anticipate that publishers will eventually begin to craft licensing agreements that require identity-based authentication, making explicit that they no longer offer IP authentication.
At the end, she makes a number of recommendations, that IMO more or less should also be included in our guidelines:
- Reach out to the campus technology unit that manages identity-based authentication systems (e.g., InCommon or OpenAthens) and engage in an ongoing discussion about privacy, user control, minimal sharing of identifiable data, etc., with the goal of developing local principles to guide data release.
- Watch carefully for licensing terms that dictate user data sharing requirements for access to content and be prepared with responses. If IP authentication is no longer an option, seek to minimize the user data that is demanded in exchange for user access.
- Review library privacy policies to make certain that the library is transparent about what data is being passed to third-party systems and what alternatives users have if they want to try to opt-out of data sharing and tracking.
- 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. [..]
Cheers,
Peter
Am 15.03.2019 um 10:34 schrieb Jiri Pavlik:
Hi,
thanks a lot, Jos, links to the documents added at Background chapter at FIM4L Guidelines and recommendations draft.
All the best
JiriOn Fri, Mar 15, 2019 at 10:03 AM Jos Westerbeke jos.westerbeke@eur.nl wrote:
Hi all,
For your interest: "Protecting Patron Privacy in Digital Resources" on Scholarly Kitchen.
Stanford library made a statement recently about patrons privacy. I think this statement perfectly aligns with our work.
It draws the libraries' concerns and underlines the importance of our work. FIM4L should have the ability to make e-resource access with SSO better than using IP based access. Libraries cannot win the fight for preserving patron privacy by keep using IP based access.
I think we even have to encourage SSO access (when Open Access without authentication is not possible) in order to "... carefully structure [SSO access] to minimize exposure of patron data as much as possible, but always to ensure disclosure of any PII that may be transmitted." According to the article.
all the best,
Jos
Jos Westerbeke
Library IT Specialist / Demandmanager | Erasmus University Rotterdam, Library | Burgemeester Oudlaan 50 | 3062PA Rotterdam | jos.westerbeke@eur.nl | +31 640295513
Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Peter G., and all,
Maybe we should have a chapter (or separate document) like "Addressing Objections" regarding the use of SSO.
And, yes, some advices like especially "Watch carefully for licensing terms" should not be lacking in our Recommendations.
I think the recommendations should go beyond SSO. For what does a SP do after authentication? (If we don't say something, they are free to go with 'their users'.
Thanks! Jos
From: Fim4l fim4l-bounces@lists.daasi.de on behalf of Peter Gietz peter.gietz@daasi.de Date: Tuesday, 19 March 2019 at 13:31 To: "fim4l@lists.daasi.de" fim4l@lists.daasi.de Subject: Re: [Fim4l] Stanfords statement
Hi Jos, hi all,
this is definitely interesting reading. Even more interesting IMHO is an article referenced there: https://scholarlykitchen.sspnet.org/2018/01/16/what-will-you-do-when-they-co... , a blog post by Lisa Janicke Hinchliffe, Professor/Coordinator for Information Literacy Services.
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:
Federated Identity (and Privacy)
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. 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. Such federated tracking is unlikely to be fully developed in the initial RA21 projects and the most pernicious form would require publishers to collaborate in data sharing in ways that they currently are not inclined to do. But, I think there is every reason to anticipate such technologies could be created in a fairly short period of time should those sentiments shift. and a little later: 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. [...] 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.
[..] publishers and platforms will likely prefer identity-based authentication mechanisms [..] I anticipate that publishers will eventually begin to craft licensing agreements that require identity-based authentication, making explicit that they no longer offer IP authentication. At the end, she makes a number of recommendations, that IMO more or less should also be included in our guidelines:
* Reach out to the campus technology unit that manages identity-based authentication systems (e.g., InCommon or OpenAthens) and engage in an ongoing discussion about privacy, user control, minimal sharing of identifiable data, etc., with the goal of developing local principles to guide data release. * Watch carefully for licensing terms that dictate user data sharing requirements for access to content and be prepared with responses. If IP authentication is no longer an option, seek to minimize the user data that is demanded in exchange for user access. * Review library privacy policies to make certain that the library is transparent about what data is being passed to third-party systems and what alternatives users have if they want to try to opt-out of data sharing and tracking. * 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. [..]
Cheers,
Peter
Am 15.03.2019 um 10:34 schrieb Jiri Pavlik:
Hi,
thanks a lot, Jos, links to the documents added at Background chapter
at FIM4L Guidelines and recommendations draft.
All the best
Jiri
On Fri, Mar 15, 2019 at 10:03 AM Jos Westerbeke jos.westerbeke@eur.nlmailto:jos.westerbeke@eur.nl wrote:
Hi all,
For your interest: "Protecting Patron Privacy in Digital Resources" on Scholarly Kitchen.
Stanford library made a statement recently about patrons privacy. I think this statement perfectly aligns with our work.
It draws the libraries' concerns and underlines the importance of our work. FIM4L should have the ability to make e-resource access with SSO better than using IP based access. Libraries cannot win the fight for preserving patron privacy by keep using IP based access.
I think we even have to encourage SSO access (when Open Access without authentication is not possible) in order to "... carefully structure [SSO access] to minimize exposure of patron data as much as possible, but always to ensure disclosure of any PII that may be transmitted." According to the article.
all the best,
Jos
Jos Westerbeke
Library IT Specialist / Demandmanager | Erasmus University Rotterdam, Library | Burgemeester Oudlaan 50 | 3062PA Rotterdam | jos.westerbeke@eur.nlmailto:jos.westerbeke@eur.nl | +31 640295513
_______________________________________________
Fim4l mailing list
Fim4l@lists.daasi.demailto:Fim4l@lists.daasi.de
http://lists.daasi.de/listinfo/fim4l
_______________________________________________
Fim4l mailing list
Fim4l@lists.daasi.demailto:Fim4l@lists.daasi.de
http://lists.daasi.de/listinfo/fim4l
--
Peter Gietz, CEO
DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany
phone: +49 7071 407109-0
fax: +49 7071 407109-9
email: peter.gietz@daasi.demailto:peter.gietz@daasi.de
web: www.daasi.dehttp://www.daasi.de
Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz
* 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
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
* Peter Gietz peter.gietz@daasi.de [2019-03-20 19:30]:
I know, but it is a common fear in the library community and we should therefore address such fears.
OK. I merely tried to analyse the arguments presented in that article and I'm happy to hear that my positions are not contentious as far as this group is concerned. (At least the Peters agree! ;))
Some other things worth mentioning:
Strategically I wouldn't want to be advocating for a regime change from IP-based auth to FIM (in case anyone assumed that), simply because the UX with IP-based auth when the subject is on-campus/on-premise is unsurpassed and can never be matched by FIM. (For off-campus/off-site it's more of the reverse, sadly, and so we want both, IMO.) FWIW, I know of one local (and not generalisable) use-case where the publisher tried to get rid of any and all IP-based access and argued this with fulfilling the academic institutions' own long-stanading requests for SAML support. (Basically: "Here's the SAML support you asked for for the last 10 years. Now it's the only access method. I hope you're happy.") I don't know where this group intends to take things but I'd agree that there's a certain danger in asking for e.g. SAML support and then losing IP-based access in the process. Though the above is the sole exception to a vast amount of e-resource providers that just added SAML to the existing methods available instead of replaced existing ones that had (some) desirable properties. (And of course managing "authorised" IP ranges is a drag, esp if done in manual out-of-band workflows. Not sure it's worth investing effort into making that more automated or scale better in the general case, though.)
The other issue is the fate of the eduPersonTargetedID attribute. I'd hate to see anything remotely resembling Best Current Practices or Recommendations, esp ones newly published, that promoted/prolonged use of this historical artefact. Of course we have to get from where we are (some existing support for eduPersonTargetedID, some existing support for proper persistent SAML 2.0 NameIDs) to SAML pairwise-id, but any language that makes continued use of that legacy attribute "OK" might be actively damaging. (Note that any IDP already supporting ePTID should also be able to support pairwise-id, it's actually much simpler. So by allowing legacy bahaviour into new guidelines this would potentially undermine global efforts to get away from ePTID.)
But let's first see whether the federation community can actually muster up their courage to finally "deprecate" ePTID. If that happens I'm firmly counting on FIM4L not to subvert this effort.
-peter
Since no one else responds, and since I have some time now, I will, but only on the IP auth subject, ePTID has been discussed a lot here and on the REFEDS list and we will find a language that quotes the RA21 recommendation and that argues that there may be better alternatives to it, which will need software changes on the SP side.
As to IP based authentication:
Am 20.03.2019 um 20:53 schrieb Peter Schober:
[...]
Some other things worth mentioning:
Strategically I wouldn't want to be advocating for a regime change from IP-based auth to FIM (in case anyone assumed that), simply because the UX with IP-based auth when the subject is on-campus/on-premise is unsurpassed and can never be matched by FIM. (For off-campus/off-site it's more of the reverse, sadly, and so we want both, IMO.) FWIW, I know of one local (and not generalisable) use-case where the publisher tried to get rid of any and all IP-based access and argued this with fulfilling the academic institutions' own long-stanading requests for SAML support. (Basically: "Here's the SAML support you asked for for the last 10 years. Now it's the only access method. I hope you're happy.") I don't know where this group intends to take things but I'd agree that there's a certain danger in asking for e.g. SAML support and then losing IP-based access in the process. Though the above is the sole exception to a vast amount of e-resource providers that just added SAML to the existing methods available instead of replaced existing ones that had (some) desirable properties. (And of course managing "authorised" IP ranges is a drag, esp if done in manual out-of-band workflows. Not sure it's worth investing effort into making that more automated or scale better in the general case, though.)
You read well that we do want to say that eventually IP based authentication should be deprecated. I see a longer migration period, and that was the reason, why we set up pilots in AARC1 that help in the migration phase, namely a SAML infrastructure that allows for IP based authentication (based on Shibboleth). In addition one pilot allowed for easily managing IP-Ranges via a web interface with the possibility to define which attributes and values should be be sent by the IdP for which IP-range with distributed management so that any number of Institutions can participate (see [1]).
What are the reasons to leave IP based authentication totally eventually?
* access will more and more be through mobile and home desktops and VPN, as you correctly indicate is everything but seamless * more granular contracts based on attributes and not for the whole institution * IP spoofing * better identification of misbehaving users, and then only blocking this user and not the whole institution * Personalization features provided by SPs * there will be a time, when ipv4 is really dead (people are saying this since more than a decade, but eventually it will be true). And in IPv6 IP based authentication might not be so easy any more, with IPv6 Privacy Extension, Authentication Header, etc. But I am no expert here and might be totally wrong on this last point. We haven't discussed this yet anyway.
Of course the publishers have invested in SAML and now they are pushing this technology also within the RA21 activity. I guess that your one case of a publisher demanding to go for SAML only will thus become more in future.
[1] https://wiki.geant.org/display/AARC/Libraries+walk-in-user+pilot
Cheers, Peter G.
The other issue is the fate of the eduPersonTargetedID attribute. I'd hate to see anything remotely resembling Best Current Practices or Recommendations, esp ones newly published, that promoted/prolonged use of this historical artefact. Of course we have to get from where we are (some existing support for eduPersonTargetedID, some existing support for proper persistent SAML 2.0 NameIDs) to SAML pairwise-id, but any language that makes continued use of that legacy attribute "OK" might be actively damaging. (Note that any IDP already supporting ePTID should also be able to support pairwise-id, it's actually much simpler. So by allowing legacy bahaviour into new guidelines this would potentially undermine global efforts to get away from ePTID.)
But let's first see whether the federation community can actually muster up their courage to finally "deprecate" ePTID. If that happens I'm firmly counting on FIM4L not to subvert this effort.
-peter _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
On 28 Mar 2019, at 7:46, Peter Gietz wrote:
Since no one else responds, and since I have some time now, I will, but only on the IP auth subject, ePTID has been discussed a lot here and on the REFEDS list and we will find a language that quotes the RA21 recommendation and that argues that there may be better alternatives to it, which will need software changes on the SP side.
It should only take configuration changes, not changes to the federating software itself, but I agree, it is important to discuss eduPersonTargetedID, since it has some major security problems. The OASIS Security Services Technical Committee (SSTC) has adopted the new SAML-level, cross-sector subject identifiers [1], which are intentionally aligned with similar constructs in the OAuth space. There are two identifiers, subject-id (analogous to eduPersonUniqueID) and pairwise-id (a case-insensitive privacy-preserving pairwise identifier).
Best,
Nick
[1] http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-i...
As to IP based authentication:
Am 20.03.2019 um 20:53 schrieb Peter Schober:
[...]
Some other things worth mentioning:
Strategically I wouldn't want to be advocating for a regime change from IP-based auth to FIM (in case anyone assumed that), simply because the UX with IP-based auth when the subject is on-campus/on-premise is unsurpassed and can never be matched by FIM. (For off-campus/off-site it's more of the reverse, sadly, and so we want both, IMO.) FWIW, I know of one local (and not generalisable) use-case where the publisher tried to get rid of any and all IP-based access and argued this with fulfilling the academic institutions' own long-stanading requests for SAML support. (Basically: "Here's the SAML support you asked for for the last 10 years. Now it's the only access method. I hope you're happy.") I don't know where this group intends to take things but I'd agree that there's a certain danger in asking for e.g. SAML support and then losing IP-based access in the process. Though the above is the sole exception to a vast amount of e-resource providers that just added SAML to the existing methods available instead of replaced existing ones that had (some) desirable properties. (And of course managing "authorised" IP ranges is a drag, esp if done in manual out-of-band workflows. Not sure it's worth investing effort into making that more automated or scale better in the general case, though.)
You read well that we do want to say that eventually IP based authentication should be deprecated. I see a longer migration period, and that was the reason, why we set up pilots in AARC1 that help in the migration phase, namely a SAML infrastructure that allows for IP based authentication (based on Shibboleth). In addition one pilot allowed for easily managing IP-Ranges via a web interface with the possibility to define which attributes and values should be be sent by the IdP for which IP-range with distributed management so that any number of Institutions can participate (see [1]).
What are the reasons to leave IP based authentication totally eventually?
- access will more and more be through mobile and home desktops and VPN, as you correctly indicate is everything but seamless
- more granular contracts based on attributes and not for the whole institution
- IP spoofing
- better identification of misbehaving users, and then only blocking this user and not the whole institution
- Personalization features provided by SPs
- there will be a time, when ipv4 is really dead (people are saying this since more than a decade, but eventually it will be true). And in IPv6 IP based authentication might not be so easy any more, with IPv6 Privacy Extension, Authentication Header, etc. But I am no expert here and might be totally wrong on this last point. We haven't discussed this yet anyway.
Of course the publishers have invested in SAML and now they are pushing this technology also within the RA21 activity. I guess that your one case of a publisher demanding to go for SAML only will thus become more in future.
[1] https://wiki.geant.org/display/AARC/Libraries+walk-in-user+pilot
Cheers, Peter G.
The other issue is the fate of the eduPersonTargetedID attribute. I'd hate to see anything remotely resembling Best Current Practices or Recommendations, esp ones newly published, that promoted/prolonged use of this historical artefact. Of course we have to get from where we are (some existing support for eduPersonTargetedID, some existing support for proper persistent SAML 2.0 NameIDs) to SAML pairwise-id, but any language that makes continued use of that legacy attribute "OK" might be actively damaging. (Note that any IDP already supporting ePTID should also be able to support pairwise-id, it's actually much simpler. So by allowing legacy bahaviour into new guidelines this would potentially undermine global efforts to get away from ePTID.)
But let's first see whether the federation community can actually muster up their courage to finally "deprecate" ePTID. If that happens I'm firmly counting on FIM4L not to subvert this effort.
-peter _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Nick,
welcome to this list. Yes Peter S. made us totally aware of the deficiencies of ePTID and we will recommend pairwise subjectID. As discussed on the REFEDS list, it will be difficult to get people move away from ePTID though ... And as to the configurability of publisher's SAML SP implementations I am not too sure (not everyone is using Shibboleth, SimpleSAMLPhP, etc.). May be someone of that community can comment.
Cheers,
Peter
Am 28.03.2019 um 17:01 schrieb Nick Roy:
On 28 Mar 2019, at 7:46, Peter Gietz wrote:
Since no one else responds, and since I have some time now, I will, but only on the IP auth subject, ePTID has been discussed a lot here and on the REFEDS list and we will find a language that quotes the RA21 recommendation and that argues that there may be better alternatives to it, which will need software changes on the SP side.
It should only take configuration changes, not changes to the federating software itself, but I agree, it is important to discuss eduPersonTargetedID, since it has some major security problems. The OASIS Security Services Technical Committee (SSTC) has adopted the new SAML-level, cross-sector subject identifiers [1], which are intentionally aligned with similar constructs in the OAuth space. There are two identifiers, subject-id (analogous to eduPersonUniqueID) and pairwise-id (a case-insensitive privacy-preserving pairwise identifier).
Best,
Nick
[1] http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-i...
As to IP based authentication:
Am 20.03.2019 um 20:53 schrieb Peter Schober:
[...]
Some other things worth mentioning:
Strategically I wouldn't want to be advocating for a regime change from IP-based auth to FIM (in case anyone assumed that), simply because the UX with IP-based auth when the subject is on-campus/on-premise is unsurpassed and can never be matched by FIM. (For off-campus/off-site it's more of the reverse, sadly, and so we want both, IMO.) FWIW, I know of one local (and not generalisable) use-case where the publisher tried to get rid of any and all IP-based access and argued this with fulfilling the academic institutions' own long-stanading requests for SAML support. (Basically: "Here's the SAML support you asked for for the last 10 years. Now it's the only access method. I hope you're happy.") I don't know where this group intends to take things but I'd agree that there's a certain danger in asking for e.g. SAML support and then losing IP-based access in the process. Though the above is the sole exception to a vast amount of e-resource providers that just added SAML to the existing methods available instead of replaced existing ones that had (some) desirable properties. (And of course managing "authorised" IP ranges is a drag, esp if done in manual out-of-band workflows. Not sure it's worth investing effort into making that more automated or scale better in the general case, though.)
You read well that we do want to say that eventually IP based authentication should be deprecated. I see a longer migration period, and that was the reason, why we set up pilots in AARC1 that help in the migration phase, namely a SAML infrastructure that allows for IP based authentication (based on Shibboleth). In addition one pilot allowed for easily managing IP-Ranges via a web interface with the possibility to define which attributes and values should be be sent by the IdP for which IP-range with distributed management so that any number of Institutions can participate (see [1]).
What are the reasons to leave IP based authentication totally eventually?
- access will more and more be through mobile and home desktops and VPN, as you correctly indicate is everything but seamless
- more granular contracts based on attributes and not for the whole institution
- IP spoofing
- better identification of misbehaving users, and then only blocking this user and not the whole institution
- Personalization features provided by SPs
- there will be a time, when ipv4 is really dead (people are saying this since more than a decade, but eventually it will be true). And in IPv6 IP based authentication might not be so easy any more, with IPv6 Privacy Extension, Authentication Header, etc. But I am no expert here and might be totally wrong on this last point. We haven't discussed this yet anyway.
Of course the publishers have invested in SAML and now they are pushing this technology also within the RA21 activity. I guess that your one case of a publisher demanding to go for SAML only will thus become more in future.
[1] https://wiki.geant.org/display/AARC/Libraries+walk-in-user+pilot
Cheers, Peter G.
The other issue is the fate of the eduPersonTargetedID attribute. I'd hate to see anything remotely resembling Best Current Practices or Recommendations, esp ones newly published, that promoted/prolonged use of this historical artefact. Of course we have to get from where we are (some existing support for eduPersonTargetedID, some existing support for proper persistent SAML 2.0 NameIDs) to SAML pairwise-id, but any language that makes continued use of that legacy attribute "OK" might be actively damaging. (Note that any IDP already supporting ePTID should also be able to support pairwise-id, it's actually much simpler. So by allowing legacy bahaviour into new guidelines this would potentially undermine global efforts to get away from ePTID.)
But let's first see whether the federation community can actually muster up their courage to finally "deprecate" ePTID. If that happens I'm firmly counting on FIM4L not to subvert this effort.
-peter _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Teilnehmer (5)
-
Jiri Pavlik -
Jos Westerbeke -
Nick Roy -
Peter Gietz -
Peter Schober