Eran Hammer – the former OAuth 2.0 specification editor – recently spoke at RealtimeConf about why he left the working group and what he perceives to be the main problems with OAuth 2.0.
RealtimeConf – “OAuth 2.0 – Looking Back and Moving On” by Eran Hammer from &yet on Vimeo.
Last week, Paul and I sat down to list the IT resources that the library offer to staff and students are and how they authenticate users. We also identified services that allow us to customise the sign in experience in order to achieve at least stage one of our strategy for consistent sign in:
1) To ensure a single, consistent identity for each person, all library (and ICT) applications that we operate internally must have Active Directory sign-in instead of local databases. Almost all of our applications achieve this already.
(source Linkey bid document – section 3.1)
Before proceeding there is some jargon to explain:
- SAM – A SAM (security accounts manager) ID is a user’s AD username. For staff this will generally be the first letter of their forename + their surname – e.g. for me this is abilbie. For students this is their student number – e.g. 01234567.
- Password – This a user’s AD password.
- Employee ID – for staff this is the ID number from our employee database. For students this is the same as their SAM ID.
- SafeCom PIN – SafeCom is our printing authentication service we use here at the university. Each staff and student has their own PIN number which they use with their employee ID.
This is the list we came up with:
- library.lincoln.ac.uk – Hosted on our WordPress platform. We can completely customise every aspect of the site. Users sign in with their SAM ID and password.
- Blackboard – Our VLE. If a user is signed in it will provide infomation about their library account plus they can pay any fines. Digitised material stored is also stored in and access is granted based on a students’ course. Users sign in with their SAM ID and password.
- Clio – inter-library loans management website. Users sign in with their SAM ID and password. We can completely customise the experience.
- EPrints – our research repository. EPrints is open source so we can change anything. Users sign in with their SAM ID and password.
- EZProxy – allows for e-resources access based on IP address proxying. EZProxy is LDAP capable however it can inherit Blackboard/SharePoint authentication sessions. We can completely customise the experience.
- Open Athens LA (Local Authentication) – Enables users to securely access to online resources. Provides Athens->Athens, and Athens/SAML->UK Federation->SAML authentication. Users sign in with their SAM ID and password. This should be installed in the coming weeks. We think we can customise the experience.
- Resources that have their own username + password. A very subset of online resources the library subscribe don’t work with Athens or EZProxy and so give us a username and password to use. Users are directed to these services through our SharePoint site and are authenticate with these services in two ways:
- The user is a presented with a 401 dialog and they have to manually enter the username and password.
- Thin Clients – The GCW library on the Brayford campus over the summer had a number of thin client computers installed. When physically in front of the computer users’ authenticate with their SAM ID and password but because these machines use virtual instances we could provide a “desktop in the browser” experience via UAG.
- Find it @ Lincoln – A search engine of journals and databases that we subscribe to that is hosted remotely by Ebsco. Authentication is delegated to EZProxy.
- RefWorks – Allows users to collect references. Authentication is via Athens. We can’t customise the look and feel of RefWorks itself but we hope we can customise how our Open Athens LA looks.
- Aspire – Reading List software provided by Talis. Authentication is via Athens. See above note about customising Athens LA.
- Journals A to Z / OpenURL resolver – As above
- Databases – A combination of Athens and EZProxy authentication.
- Printing – The physical printers in the library require authentication using a user’s employee ID and their PIN number.
- Self service kiosks – These kiosks authenticate users by requiring them to scan their staff/student card (which has a code 39 barcode of their employee ID and then typing in their PIN onscreen. We can’t customise this experience.
- Print top up kiosks – These kiosks authenticate users by requiring them to type in their SAM ID and password. We can’t customise this experience.
Visually of this looks like:
When the UAG is installed we should be able to easily hook up services that require SAM ID and password over LDAP. Other services that use alternative authentication such as HIP will require us to write some middleware that will translate between SAM ID + password to employee ID + PIN.
Assuming it is as simple as that, then when these services are hooked up to the UAG then the map will look like this:
The model assumes that eventually the UAG will be like a Gateway for users to access most resources.
LDAP inject means that once a user has authenticated with the UAG their SAM ID and password will be stored in a session, and then when the user visits a service that uses LDAP authentication to the AD, UAG will inject their username and password into the sign-in form and click the submit button for them. At the end of the day single sign-in is essentially a user experience which takes some of the pain with accessing resources away from them.
The IETF has approved the OAuth 2.0 Core and Bearer specifications and have now been published as RFC 6749 (Core) and RFC 6750 (Bearer).
Dick Hardt, one of the editors of the spec has summarised three important enhancements that OAuth 2.0 has over the old 1.0a spec:
- Simplicity: Client developers don’t need to do any cryptography or use a library to call OAuth 2.0 protected resources. The token can be passed in the HTTP headers or as a URL parameter. While HTTP headers are preferred, a URL parameter is simpler and allows API exploration with a browser.
- Token choice: implementers can use existing tokens that they already generate or consume. There are extension points so that the client can sign the token instead of it being a bearer token.
- Separation of roles: if the token is self-contained, then the resource can verify the token independently of the authorization server. Resources don’t have to call back to the authorization server to verify the token on each call, enabling higher performance and separation of security contexts.
Yesterday I travelled to Birmingham for a JISC AIM programme meeting at the beautiful Aston University campus.
I presented a short talk about the Linkey project. My slides are embedded below. Note, I don’t really like very “wordy” presentation slides so I keep them simple, however you should be able to get the gist of the talk 🙂