David Orrell, System Architect and Phil Leahy, Service Relationship Manager, talk about Phase II of the OpenAthens Cloud Service Provider project, and also about how OpenAthens is being used as an identity provider service in the corporate sector.
2. OpenAthens Service Provider as a service
• Phil Leahy (OpenAthens Service Relationship Manager)
• David Orrell (OpenAthens System Architect)
3. OpenAthens for corporate customers
• Our roots are in UK academia and healthcare, plus…
• Ministry of Defence
• House of Commons Library
• Healthcare organisations in the US, Spain & Australia
• US Department of Defense
4. Publisher 1
Publisher 2
Publisher 3
Publisher 4
Banking/finance
company
Legal practice
Pharmaceutical
company
Petrochemical
company
Corporate/publisher relationships
150 other
publishers
Other research activity
SAML connection
5. Other access tools persist
• IP authentication
• Publisher-issued credentials
• Pre-loading data
• Domain-matching
• …but none of them tell you anything about your users
6. Local authentication tools in OpenAthens
• Shibboleth/SAML
• ADFS
• LDAP
• SirsiDynix
• PING Federate
• other SAML systems
• All of these can use attribute release in OpenAthens
8. Resource Access for the 21st century (RA21)
• Joint initiative between NISO and STM Association
• Announced at Frankfurt Book Fair
• Meetings in London in December
• OpenAthens is part of the conversation
9. 1. Authentication: Providing the best possible end-user
experience
2. Single Sign-On: Enabling simple SSO within publishing
platforms
3. Establishing standards: Driving common standards for
interoperability
4. Facilitating discussions: Providing forums for discussion
5. Embracing change: Understanding that change is constant
12. • State of Identity Management and Federated Identity in
2016
• Our plans for OpenAthens SP
13. Federated identity management
• Adoption continues to grow
“Through 2016, Federated Single Sign-On Will Be the Predominant SSO
Technology, Needed by 80 Percent of Enterprises” – Gartner
• New generation of standards are here
• OAuth/OpenID Connect
• ...and emerging
• UMA (user-managed access)
14. How well does SAML fit today?
• Mature standard, widely adopted
• Many moving parts
• metadata ~10s of megabytes
• possibly addressed by MDQ protocol?
• ...but SAML is widely deployed by organisations
• Developers at ease working with JSON, REST APIs
• consume and integrate cloud services
• loosely-coupled and ‘version-less’
• micro-services vs monolithic
15. How well does OpenAthens SP fit today?
• Server modules have limited integration options
• servlet-filter, Apache module etc.
• difficult to test
• may not align well with modern architectures
• Limited APIs
16. Customer feedback
• Not familiar with concepts of federated identity
• Installation and configuration steps unclear
• Changes take too long to take effect
• or require contact with Service Desk
• Locally installed software required
• prefer to use an API
• Integrating with multiple applications is complex
• duplication of configuration and registration
• End-user experience inconsistent and confusing
Phase 1
Phase 2
17. SAML connector
Future OpenAthens SP
Identity
provider
Service Provider
Identity
provider
Identity
provider
App1 App2 App3
SAML
OAuth/OpenID Connect
REST
Multiple applications can
share the same connector
SAML connector available
as a service
DashboardOpenAthens
18. OpenID Connect
• Identity layer on top of OAuth 2.0
• Industry-wide adoption
• Developer friendly
• Wide variety of clients including JavaScript and mobile
• Supports range of deployment scenarios
19. • Dashboard provides
• Configuration
• Access to logs
• Analytics
• Add additional applications without having to register
multiple SAML entities
OpenAthens SP Cloud
20. Federated login: UX issues!
• One of the most common user complaints!
• Users presented with too many options
• “OpenAthens login”
• “Shibboleth login”
• “Institutional login”
• “Choose you federation”
• Drop-down lists of organisations
• Search for organisation
• …
• Users often don’t even understand the question!
21. Current options for discovery
• By-pass completely (WAYFless URL, OA redirector)
• Use a federation discovery service
• Does not work across multiple federations
• Does user know their federation?
• Build your own using OpenAthens SP API
• Build your own using your own data
22. Federated discovery as a service?
• A more opinionated approach to discovery UX
• Consistent but brand-able via dashboard
• Will work out-of-the-box
• Delivered via:
• Standalone hosted service
• Embeddable JavaScript widget
• REST APIs still available to build your own
• Independent of a given federation but will support any
Afternoon slot
Welcome to the second publisher breakout session. You already know who David and I are, and in this session we’re going to be talking about Phase II of the OpenAthens Cloud Service Provider project, and also about how OpenAthens is being used as an identity provider service in the corporate sector.
Firstly, here’s David to talk about what we’re going to be doing in Phase II.
I’m going to talk now about how OpenAthens is already being used in the corporate sector, and how we believe publishers can benefit from enabling access to its content via the same routes as those traditionally used by the academic, research and healthcare sectors.
And that is where OpenAthens is recognised as having its roots. We started by providing single sign-on services initially for the UK academic sector, followed closely by the UK National Health Service, but our customer base has been wider than that for some time now.
Fast-forwarding around fifteen years presents a more complex picture: publishers and subscribing organisations alike are coming to realise the OpenAthens Federation is the only scalable SAML/Shibboleth option available to non-academic organisations. Every other access management federation has ring-fenced its membership to the academic and research communities because of the way in which they’re funded, but we’re increasingly seeing questions from publishers on whether they can use the access routes originally provided for academic and research organisations for any customer type.
And the reason we’re seeing these questions is because the way in which many corporate organisations want to connect to a publisher’s platform isn’t necessarily the most efficient or secure.
So here’s an illustration of what typically happens. SAML has made connecting with customers much easier. [CLICK] Get their Identity Provider certificate or metadata or both, and integrate them into your access management system. Perhaps you’ll need to supply the customer with login and logout URLs. You might require them to pass you their users’ email, firstname, and lastname. If you’re lucky, you can get them to adhere to specific attribute namespaces too. All of that is development work.
Then you’re asked do that for the next customer [CLICK], and the next and the next and the next and the next, until you’ve ended up with a series of expensive, parallel, single-use connections, each with their own dependencies.
And those customers are asking their other suppliers for exactly the same thing [CLICK].
But SAML is not plug’n’play technology, and each of those connections will need testing. And won’t be your customer services team doing that work – it’s probably your development team. That makes it an expensive task. And in all likelihood, it’s a developer involved at the customer end too, so it’s not a cheap solution for anyone.
A number of other methods are still around, none of them particularly responsive or secure, and with little or no information about who is looking at your content. For example, it could be a finance director, or clinical services director, who’s looking at your content a few times a year but you’ve got no way of knowing that using any of these methods.
[list each method’s drawback]
Shibboleth was supposed to replace some or all of these access methods, at least in those traditional STM sectors, and in Europe that has been pretty successful. But there are no technical reasons preventing other organisation types from using the same access methods.
During his talk this morning, David talked about attribute exchange. The OpenAthens Federation allows service providers to go to their corporate customers and say “send me some data about your users and we can make it a richer experience for them.” Attribute release has never been easier to manage for subscribing organisations, and OpenAthens provides the tools for them to do this quickly and easily.
David mentioned these connection methods this morning as those we’re currently supporting in OpenAthens, and each of them offers publishers the same advantages of efficiency and security as they already have for the academic, research and healthcare sectors. Corporate customers can join these sectors in using these technologies to hook into their organisation’s directory services, allowing publishers to leverage the daily identity management tasks that take place in every organisation. When someone joins an organisation as a new employee, they’re given a record in (say) their Active Directory. Their login will give them access to specific network drives, to the printers, and perhaps to specific offices or buildings in some cases. All this will be because of certain properties given to their directory record.
At the same time, if that company is one of your customers and they’re logging in via the OpenAthens Federation, they will have automatic access to their subscriptions without requiring any other tasks to be completed, and without needing a separate username and password whether that’s for their company VPN or a publisher’s login credentials.
I just mentioned that we’d made it easier for customers to release additional data about their users. That could be forename, surname and email address so that first-time users aren’t required to complete a registration form, or it could be something more interesting like a job role or department, to help you identify the content that finance director is viewing. More than that, perhaps you want to authorise access to premium or sensitive data to specific job roles or individuals.
The tools to experiment with attribute release are in your grasp. The same OpenAthens credentials you use to login and configure our software can be used to access our user management dashboard and configure both standard and custom data attributes for release, and here is Adam Snook of our presales team is here to show you how.
---
We’re now beginning to see a much more positive attitude to attribute release, as the people involved in making these decisions are much more comfortable with the data protection issues involved. It is possible to release specific attributes to specific publishers, so it’s not a case of opening the floodgates and letting every publisher get access to every piece of account data. Subscribing organisations realise they retain complete control over attribute release.
I want to briefly refer to a new initiative which has only just been announced, and which plays directly into this topic.
RA21 is a joint initiative between the National Information Standards Organization and STM Association who are essentially asking the question: can we all do better at access management?
some commercial organisations are happy to use the federated access management ecosystem pioneered by the academic access management federations
Some corporates want a better degree of frictionless content, but with the granularity of federated access management
RA21 will coordinate a study to identify the best options and work with pilot sites
OpenAthens is committed to participating in this project and to promoting the best practice and any new standards which emerge as a result.
We’re also committed to making these standards available via a common interface. We work hard to ensure publishers don’t need to know which identity provider products our mutual customers are using in the OpenAthens Federation, and we’ll be taking the same approach with the outputs from this initiative. We want to make any standards which arise as transparent to service providers as possible.
Which brings us back to the OpenAthens Publisher Manifesto. RA21 has clearly come about because NISO and the STM Association have been hearing similar things to us. While Shibboleth and SAML have enabled the adoption of common standards and removed some barriers to access, people are now asking if it’s enough?
I’ve already referred to how Shibboleth has promoted the adoption of access management standards in Europe, but it’s a different story in the US where it hasn’t gained the same level of traction. The Coalition for Networked Information (CNI) reported earlier this year that although most US institutions are members of In Common, the US access management federation, they’re not using it as an access route for subscription content. So it is obviously not seen as a good option there.
David has also talked today about our plans for ‘federated discovery as a service’ (FedDaaS), which will be another way of shaving a few rough edges from the user journey. It will contribute to the very first item on this list, just as the RA21 project is intended to do, and we’ll be telling you more about this project as it emerges.
Thanks for your time, and it’s time for your questions.