This talk was provided by Phil Leahy of OpenAthens during the NISO Live Connections event, Digital Libraries: Authentication, Access & Security of Information Resources, held on May 22-23, 2018 in Baltimore, MD.
2. openathens.orgopenathens.org
Coming up
• The access management toolkit
• What is federated access management?
• Why is a federation involved?
• InCommon, the OpenAthens Federation and more
• Challenges and limitations
• What’s next?
4. openathens.orgopenathens.org
What is federated access management?
• Secure access to digital content and services via single
sign-on
• Authentication federated to the home organisation
• Individual accountability
• Permission- or role-based authorisation
• SAML encrypts and digitally signs all transactions
5. openathens.orgopenathens.org
How federated access management works
Standard processes to enable access to:
• Desktop or cloud office applications
• Network drives (filestores etc.)
• VLE and/or LMS
• Discovery tools
• Printer
• …and subscription content
6. openathens.orgopenathens.org
InCommon, the OpenAthens Federation and more
• Academic/research federations nationally
• OpenAthens Federation for everyone else
• Funding is the key
• Benefits
• Common technical framework (with minor policy
differences)
• Wider distribution of implementation costs
7. openathens.orgopenathens.org
Why is a federation involved?
• SAML is not ‘plug’n’play’ technology
• Technical infrastructure and policy framework
• Integrate once, re-use for multiple products/ services
• Institutions can connect to any participating publisher
• Publishers can connect to any participating Institution
10. openathens.orgopenathens.org
Challenges and limitations
• SAML and Shibboleth are over 15 years old
• Access to IT resources
• Robust identity management processes
• Myths about SAML
• Network security
• Privacy
• Finding a scalable, truly cross-sector solution
12. openathens.orgopenathens.org
What’s next?
“It is time for a major commitment from the scholarly information ecosystem of
libraries, publishers, university IT, and intermediaries… to develop a single user
account for all scholarly e-resources. This account would not only provide
authentication via a researcher’s institutional credentials but also would be the
vehicle through which a variety of additional data-driven services could be provided
on an opt-in basis. The account itself as well as the data it contains would be under
the control of the researcher, and it would therefore travel with the researcher when
changing institutional affiliations.”
Meeting Researchers Where They Start: Roger Schonfeld, March 26, 2015
https://doi.org/10.18665/sr.241038
Security through obscurity: “Security experts have rejected this view as far back as 1851”
https://en.wikipedia.org/wiki/Security_through_obscurity
Institutional U/Ps have been shared as long as they have been available – SciHub is only the latest evidence of that.
Users automatically onboarded when their network account is created
Consistent, personalised user experience, creating more opportunities to discover, access and engage with content.
Easier to comply with restricted content licences
A users home organisation verifies their identity at log in and passes encrypted attribute data to the service provider who then authorises access to their content.
As the limits of IP recognition are increasingly exposed from both a usability and security point of view, so more secure standards such as SAML-based SSO are emerging as the best way to ensure services are protected against misuse. SAML brings a number of benefits.
It allows organisations to send information to content providers securely. By default, SAML digitally signs and encrypts all data sent in each direction. This helps to:
prevent fraudulent use or interception
keep all user information private, including their login details
SAML also gives organisations granular control over what attributes are exchanged with particular resources. So an organisation could pass a forename, surname and email to one publisher, but restrict all the others to seeing only their job role, or subject specialisation.
And of course that means it enables personalisation. Without personalisation, none of the benefits of a modern digital service are available, i.e. more engagement, attracting users to return, learning more about their needs and tailoring products accordingly.
That level of detail helps everyone. It helps content providers segment their products and direct it at particular users, and by providing greater transparency of how collections are being used, it helps an organisation make more informed purchase decisions.
And in these days of greater compliance requirements, SAML helps content providers and their customers conform to best practices which meet contractual expectations around securing access to information resources.
But most importantly, it provides a superior end-user experience regardless of whether they are accessing resources from within an institution’s network or on the go.
Here’s a typical scenario: when a new user enrols at a university or starts work at a new job, that organisation will have a process which automatically grants access to the internal and external resources they need to participate in their course or do their job.
That process applies the appropriate permissions and controls to ensure they can only access what they entitled to and will typically include access to their nearest printer, the network drives for access to the documents they need and increasingly, their organisation’s subscription content – all with a single username and password.
Your institutions' licence fees pay for everything a publisher uses, from paper clips to cleaning services to access management solutions. If driving users from multiple customers to a single access point is cheaper for service providers, it ought to be cheaper for institutions
The InCommon Federation is the U.S. education and research identity federation, providing a common framework for trusted shared management of access to online resources.
SAML 2.0 offers many different options on passing attributes, how to use PKI (certificates) and other implementation details
Most access management federations have broadly similar policies
Implementation differences are usually minor but each has to be coded for
So here is what we often see of how SAML is deployed between content providers and their customers. When a subscription is put in place, a content provider might say “we can connect via SAML if you like”.
[Publisher speaks to Customer One]
[Publisher speaks to Customer Two]
[and so on and so on]
[Customer One speaks to Publisher Two]
What you end up with is a series of parallel, single-use connections which can’t be re-used and which have to be individually managed. This is not an efficient model.
But every single one of those conversations requires a developer, not just for the publisher's platform but at the customer end too. If the organisation has limited technical resources, which is often the case with SAML, that task will be outside their technical comfort zone and they can struggle to complete the integration. That makes it both a difficult and expensive option for everyone. It’s already expensive for publishers simply because a developer is involved.
But even then, using SAML doesn’t guarantee a consistent and repeatable setup. I was copied into an email conversation between a content provider and their customer where over the course of a couple of weeks, five different user ID formats were considered for use in the SAML transaction.
Then I saw quotes such as:
“it doesn’t look like the NameID matches what we have on file”
“The difference was SAML ACS URL wasn’t capitalized. They have to match exactly”
After all of that, the user IDs had to be uploaded into the content provider’s platform before anyone could use it. So onboarding new users requires additional technical tasks.
I would ask two questions of those publishers:
Why are you asking your customers to perform technical setups for which the majority won’t have the expertise?
Shouldn’t you be allowing your developers to support and develop your core business, rather using than a technology with its own management overhead?
Let me be clear: this is federated access management, because authentication is federated to the subscribing organisation and they manage their own user records. However, as I previously said it is a series of parallel, single-use connections which can’t be re-used and have to be individually managed. That is not efficient.
But could a content provider's developers complete an integration task once, and then re-use that multiple times? The answer to that is: Yes.
The OpenAthens Federation allows content providers to integrate once, and re-use this for multiple customers.
SAML is heavyweight technology
Ongoing maintenance required
Specialist knowledge is in short supply
OIDC already seen as an alternative by some
Hospitals tend to have extremely locked down IT environments, some hospitals more than others…The hospital IT department does not care about the library. Hospitals already hooking their ADFS identity management layer into OAFed.
Federated access management works best when everything is hooked in but org-wide IDM strategy can be intimidating
OIDC or other emerging web services/APIs
Roger Schonfeld and others have been advocating this for some time – but the privacy issues remain
Concept of interoperability now well-established
OIDC or other emerging web services/APIs
Roger Schonfeld and others have been advocating this for some time – but the privacy issues remain
Concept of interoperability now well-established
Free ebook! Written by Kristina Botyriute, OpenAthens Lead Technical Pre-Sales Consultant, to help information professionals confidently address authentication issues and challenges.
The difference between authentication and authorisation
Web based authentication
IP address recognition
What SAML is and how it works
OpenID Connect
Basic troubleshooting