Monthly Archives October 2012

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:

  1. Horizon Information Portal (HIP) – This service allows staff and students to interact with things they’ve borrowed or want to borrow, for example renewing and reserving books and viewing fines. We can edit XSL files which allow us to change the design of HIP. We can also add JavaScript files. HIP authenticates with a user’s employee ID and PIN number.
  2. 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.
  3. 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.
  4. Clio – inter-library loans management website. Users sign in with their SAM ID and password. We can completely customise the experience.
  5. EPrints – our research repository. EPrints is open source so we can change anything. Users sign in with their SAM ID and password.
  6. 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.
  7. 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.
  8. 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:
  9. The username and password are automatically injected into the service’s authentication screen with a JavaScript script or
  10. The user is a presented with a 401 dialog and they have to manually enter the username and password.
  11. 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.
  12. 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.
  13. 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.
  14. Aspire – Reading List software provided by Talis. Authentication is via Athens. See above note about customising Athens LA.
  15. Journals A to Z / OpenURL resolver – As above
  16. Databases – A combination of Athens and EZProxy authentication.
  17. Printing – The physical printers in the library require authentication using a user’s employee ID and their PIN number.
  18. 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.
  19. 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:

http://i.imgur.com/nEKo4.png

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:

http://i.imgur.com/dyV6C.png

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:

  1. 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.
  2. 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.
  3. 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 :)

Tim Bray, a developer at Google who I disagreed with in a previous post has just posted on his blog that the team he is currently working in is going to shortly be announcing some of their early work and thinkings soon.

He says problems they’ve identified and they want to try and solve include:

  • The username/password dance sucks and doesn’t scale, particularly on mobile.
  • People putting up apps and sites regard identity — getting people signed up & signed in — purely as a tax; something they gotta do, but unrelated to what they care about.
  • Most developers don’t understand identity standards like OAuth, or the related crypto and signing technologies, don’t want to learn them, and shouldn’t have to.
  • If you can get new arrivals signed up quicker with less work, that’s a good thing.
  • If you can get people you know signed in quicker, ideally with one click, that’s a good thing.
  • People are paranoid and really don’t want to be in the headlines for next week’s embarrassing password leak.
  • People don’t want to think about privacy and tracking and transparency, but the risk of not doing so (just) exceeds the pain.
  • People like the notion of outsourcing the icky identity work, but are nervous about putting all their eggs in the Facebook’s or Google’s or Yahoo’s or whoever’s basket.
  • On the other hand, having a cluster of Sign in with… buttons on your landing page dilutes your brand and feels like watching NASCAR on TV.

I’m looking forward to seeing what they come up with.