2. www.openathens.org
Lower barriers to your knowledge assets
• enable users to access your digital content through
secure federated single sign-on
• anytime and anywhere
• increase user engagement
• save time and money on developer costs and ongoing
maintenance
3. www.openathens.org
Lower barriers to your knowledge assets
• What is OpenAthens?
• Other access management options
• What does an access management federation do?
• OpenAthens Cloud
4. www.openathens.org
What is OpenAthens?
Helping over 2,000 organisations
in 48 countries enable access to
hundreds of thousands of journals,
databases and ebooks for over
4 million end users
7. www.openathens.org
Are you really making it easy for users?
• IP authentication does not exist
• IP recognition
• recognises the organisation, not the user
https://twitter.com/elbanoitca/status/905652549646147584
• IP authentication does not exist
In working with a variety of publishers, partners, customers, and libraries,
we frequently see access to research resources provided to members as a
benefit of their affiliation. Part of this arrangement is typically that the
institution or library will want to use their membership database to provide
access to these resources. IP recognition simply doesn’t work in these
situations.
Timothy Lull, VP of Sales, Software as a Service,
EBSCO Information Services
(OpenAthens 2016 white paper: Approaches to authentication: the importance of information security)
8. www.openathens.org
Can we use SAML?
• well-established and widely-deployed
• exchange information about users securely
• enables seamless personalisation
• helps meet compliance requirements
11. www.openathens.org
The OpenAthens Federation
• Also uses SAML/Shibboleth, but…
• …integrate once, re-use multiple times
• removes need for FTP process
• direct link to your customers’ user directory
• shifts on-boarding to Customer Services
12. www.openathens.org
Why are there so many federations?
• Mid-2000s: access management federations launched in
several countries
• Membership restricted to academic and research
communities in each country
• The OpenAthens Federation is the only commercial,
multi-national federation
https://refeds.org/federations/federations-map
13. www.openathens.org
SAML/Shibboleth can be hard
• Many small/medium publishers can’t participate
• lack of technical resource
• can't use in WordPress/other CMS platforms
• Distraction from core business
• Open source ≠ zero cost
14. www.openathens.org
• Benefit from SAML without installing it
• OpenAthens Cloud offers the same benefits
• OpenID Connect is the hook…
• …but what is OpenID Connect?
There is an alternative
15. www.openathens.org
OIDC and SAML attributes
OpenAthens
Cloud
Discovery (Where Are You From?)
Click login
OpenID
Connect
Username
Password
SAMLOIDC
Adams College
Your application User organisation Login:
Your content
18. www.openathens.org
• remote access anytime and anywhere
• secure your content through federated single sign-on
• reduce developer costs and maintenance
• increase user engagement
• don’t give users a reason to look elsewhere
OpenAthens Cloud
I’m going to talk about how your business can benefit from our cloud-based access management solution which includes membership of the OpenAthens Federation, the only international and commercial access management federation in the world. This solution will let you:
enable users to access your digital content through secure federated single sign-on
anytime and anywhere
increase user engagement
save time and money on developer costs and ongoing maintenance
In order to illustrate how OpenAthens can help content providers meet those objectives, I’m going to talk about:
what OpenAthens is
other access management options used by content providers
I’m going to spend some time explaining what an access management federation is for
And finally I'm going to talk about our new product, OpenAthens Cloud, and how it can simplify access management for publishers.
So firstly: what is OpenAthens? It’s a set of products and services which allow content providers to make their products available to their customers in a single sign-on environment. Rather than force users to remember which set of credentials they need to access a product, or require them to appear to be on-site whether they really are or not, OpenAthens lets users access all their organisation’s subscription content with a single account using a browser on any device.
This means publishers can add their content to a user’s existing portfolio instead of existing within its own silo. We’ve got ten years experience of developing Shibboleth and SAML software which has been used by some of the largest content providers exhibiting here.
The OpenAthens Federation is the trust authority which allows content providers and their customers to connect to each other without requiring technical setup each time.
More than 2,000 organisations in 48 countries have joined the OpenAthens Federation, with more than 4 million users benefitting.
As you can see, we are particularly strong in North America and Australia, and this year we appointed a sales manager in the Far East and Australasia so we can increase our growth in that region.
Federated access management allows publishers to link their products to an organisation’s daily identity management processes. 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 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.
By adding your products to that ecosystem, your customers are automatically onboarded and have access to your products on their first day without needing to learn any new steps or use anything other than a web browser.
OpenAthens makes this easy for your customers by allowing them to integrate with the OpenAthens Federation in a number of ways. In recent years this has been by using commonly available connectors with services such as Microsoft’s ADFS, or with LDAP, a less complex directory service. This means changes to user records made by your customers are immediately available to all participating content providers, whether that is adding or removing users, or updating their privileges.
But before we look more closely at OpenAthens, I want to talk briefly about other access management options which are widely used by content providers.
We don’t refer to IP authentication at OpenAthens; instead we refer to IP recognition because with that method you really don’t know who a user is.
IP recognition serves basic requirements for granting access to resources but there are some fundamental problems with it: [TAP]
prone to misconfiguration: it’s either simply wrong or a range is too wide
no granularity, e.g. the user’s department, or their subject speciality
requires significant workarounds that include additional login prompts or third-party software to bridge the gap between the user’s real location and the content itself
increasingly expected to handle authentication scenarios it was not designed for, and which institutions and content providers are asked to support, because there is no granularity.
[picture]
That means there’s no accountability, so misuse can go undetected
limiting the mobility of users can encourage bad behaviour like the use of open proxies/Sci-Hub
highly vulnerable to attacks
limitations around tracking usage and gaining insight into user activity can also prevent making more informed purchasing decisions.
[Read Tim Lull quote]
I’ve been hearing abut the end of IP recognition for most of my 17 years with OpenAthens, yet we still see anecdotal reports that most publishers attribute around 90% of usage to IP recognition. If you feel you have no alternative, that might be understandable – but is that really true?
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.
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.
Other access management federations such as the UK Access Management Federation, InCommon in the US, DFN here in Germany and others use the same model. So we operate in the same way technically, we only differ in our membership.
Content providers have that direct link to a customer’s user directory, and it doesn’t require a developer to enable mew subscriptions. Instead, it’s managed by Customer Services which is cheaper for content providers, and cheaper for their customers.
But why can't publishers use just one federation?
Here's a world map of countries with national access management federations. Those in red are production federations and those in purple are still being piloted. But what role do they play?
I talked about a trust authority at the beginning. Access management federations provide a series of rules between IdPs and SPs which enable them to trust the information they send between one another, and ensure the minimum amount of personal data is exchanged in a secure and consistent way. Thanks to these policies, a federation helps keep user details secure. Their personal information is stored only by their Identity Provider, with relevant attributes exchanged with SPs . This minimises the opportunities for data breaches or the theft of personal information.
[TAP]
Each of these federations is funded by public money, so membership is restricted to academic and research communities in each country. The OpenAthens Federation doesn’t have the same funding model. This means that:
organisations in fields as diverse as healthcare, pharmaceutical research and development, commercial companies, defence and government organisations can benefit from the same tried‐and‐tested access pathways originally put in place to serve the academic sector
The OpenAthens Federation operates across national boundaries
But although a federation will provide a consistent set of rules for all members of that federation, there are minor differences in how those rules have been applied. SAML is not plug'n'play technology so it's not possible to use a single configuration for every federation. OpenAthens has been building software products for over ten years which make it easy for content providers to participate in all these federations – and here is why content providers use us.
A content provider may only have:
A web developer who can manage the hosting of their content, but not necessarily an access management system
If the content is hosted in a CMS or by a hosting partner such as GoDaddy or Squarespace, it is probably sharing a server with other GoDaddy or Squarespace customers. Therefore in many cases it is not possible to install Shibboleth/SAML software in these shared environments.
[TAP]
Your technical team are already good at supporting your core business - you may not want them to have to learn a new technology
Nothing is “free”. I’ve already talked about that two-week email conversation between two sets of developers – that wasn’t a zero-cost discussion. But more significantly, deploying support for SAML typically requires a dedicated server, which in turn needs to be kept up-to-date.
But there is an alternative. It is now possible to derive all the benefits which SAML brings without having to deploy it. As I said earlier, OpenAthens has ten years’ experience of developing SAML software and having seen the issues which I just described for some time, we decided to take a new approach and developed OpenAthens Cloud.
The only technology you need to deploy in your platform is OpenID Connect – everything else is managed in our web dashboard. OpenID Connect is supported by key industry players like Symantec and Microsoft. It's a newer technology than SAML but unlike SAML, it's extensible to web-based native apps as well as mobile applications.
Maybe your platform is already using OpenID Connect? If not, I’m sure many of you will be familiar with seeing Google login options on a number of web services – that process uses OpenID Connect and as you can see, one of the benefits is a consistent login experience.
And anytime you see a PayPal payment option on a website, it is using OpenID Connect to let you login via PayPal.
Let me be clear: OpenAthens Cloud alone won't let you add Google and PayPal login options to your products. But if that is on your wishlist, with OpenID Connect as the foundation that task would be easier.
This diagram shows a typical flow – here’s a content provider’s platform with a login page. The user clicks on login and the OpenID Connect integration passes the login request to the customer’s login page, which allows the user to sign in. A successful sign-in results in SAML attributes being passed back to the platform. One of those attributes will be an organisational identifier which is used to check for a customer record. If a match is found, the user is let in – so the content provider always has control over who can access their content.
This is just a brief look at the dashboard. Setting up a new connection is quick, and as you can see here, if a content provider is already using SAML in other access management federations, it can re-use the same service provider deployment in the OpenAthens Federation. In other words, if a content provider is already using SAML to enable access to academic and research organisations, it can use the same implementation to enable access to corporate, defence and healthcare customers.
Creating an OpenID Connect connection requires completing a few fields, after which it is a matter of creating the rules which will be used to retrieve the SAML attributes required.
I’ve already said that different countries have minor differences in how they manage their federations. The OpenAthens Publisher Dashboard smooths out those differences and lets content providers enable the federation configurations they want with one click.
This is the list of access management federations currently supported in the dashboard, and others can by added via customer request.
So this is where we came in.
Removing barriers to your content enables users to access it anytime and anywhere.
[TAP]
Secure federated single sign-on technology means users are authenticated by their home organisation, so you don’t have to worry about storing their credentials or data protection issues
[TAP]
save time and money on developer costs and ongoing maintenance by using next-generation OpenID Connect technology which can be used on a wide range of platforms and devices. It is also more secure than IP recognition, so if a breach of licence occurs you can more easily identify and block individual users.
[TAP]
increase user engagement
don’t give users a reason to look elsewhere
[TAP]
Because you don’t want to give users a reason to go elsewhere:
#icanhazpdf
Sci-Hub