Libraries have long used IP-based access to grant access to online publisher resources. However, several developments mean this access model is no longer sufficient:
- Users increasingly require access from ‘any location’;
- Libraries and publishers want more granular control over access to target abuse (only block the abusing user instead of the whole library or institution);
- Libraries want more control to allow access for only certain groups or faculties, when access for everyone is not an option (e.g., for discipline-specific resources). This allows for smarter (cheaper) contracts.
- Publishers want to be able to offer a more personalized experience to users;
- Libraries and users find VPN-technology to be time-consuming and complex.
In order to solve this, most parties have agreed that federated authentication with Single Sign-On (SSO) is the way forward. Using SSO, a user logs in with an identity that allows an institution to testify whether he/she has a certain relation with them. This is expressed in the form of attributes, which can be used to check whether someone should be allowed access. However, there are still a number of issues which stand in the way of wide-spread adoption of SSO:
- For publishers and libraries:
- It is complex and expensive when publishers and libraries need to negotiate every time about what attributes to release.
- Misunderstanding, miscommunication and/or misconfiguration:
- Some libraries are unfamiliar with options federated technology offers for combining easy secure access while preserving privacy.
- Providers of attributes sometimes don’t release the correct set or correct values, causing problems in accessing resources.
- Service Providers sometimes request more attributes than necessary / providers sometimes (agree to) release more attributes than strictly necessary, hurting the privacy of the user.
- The way federated authentication is offered by the various publishers differs greatly.
- This results in confusion for end users.
- There are many different situations:
- Some publishers want to receive none or hardly any personal data, while in some cases parties agree that their specific scenario requires some extra attributes to be released. Guidance on common scenarios and what to do could help.
All of these issues cause libraries headaches about what their policy should be and lead to many discussions and delays in the contractual phase.
To improve the situation, the FIM4L workgroup has three key priorities:
- Priority #1 – To come to a consensus on library policy for federated authentication that protects users identities. This policy should help libraries and publishers and needs to be clear for account managers, license managers, etc. (those who make the deals), while also including enough technical information for IT staff.
- Priority #2 – To seek broad support for the policy amongst libraries and publishers.
- Priority #3 – To promote the use of uniform implementations of authentication procedures by service providers
- Collect libraries’ requirements for Federated Identity Management (FIM) and share them with relevant groups like SeamlessAccess, FIM4R, REFEDS and the eduGAIN;
- Draft guidelines and recommendations for attributes release that respect users’ privacy and allow SSO for personalisation with users consent;
- Increase awareness of the existence of federated authentication amongst people responsible for purchasing electronic resources;
- Advocate for making federated authentication a requirement during the negotiation phase (if/when possible);
- Promote the adoption of state-of-the-art and privacy preserving Federated Authentication and Authorisation Infrastructure (AAI) and principles (including attribute release) by libraries from research and educational institutions in particular but also all other libraries in general, as they would benefit as well;
- Liaise with SeamlessAccess and REFEDS with respect to recommending best practices for exchanging attributes between libraries and publishers, focusing on two key questions:
- Which attributes (e.g., persistent identifier, affiliation, etc.)?
- What to do with additional (demanded) Personally Identifiable Information (PII) sign-ins for service personalization?