Tag: authentication

Authentication in the Library

Alex Bilbie / / In depth

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.

How OAuth 2.0 works

Alex Bilbie / / Nutshell

The following sequence describes how the OAuth 2.0 web-server flow works. The web-server flow is the most common OAuth flow which most implementations support.

Before we begin there is some terminology that needs to be understood:

  • Resource owner (a.k.a. the User)
    An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
  • Resource server
    The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
  • Client
    An application making protected resource requests on behalf of the resource owner and with its authorisation. The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices).
  • Authorisation server
    The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorisation.

The web-server flow

1) The client redirects the user to the authentication server with the following information

  • The client’s ID (client_id)
  • A redirect URI where the user will returned to after they’ve authenticated with the authentication server and approved the client (redirect_uri)
  • The type of response that the client accepts (response_type)
  • A list of data which the client wishes to access on behalf of the user (scope)
  • A state parameter which is an anti-CSRF token (state)
	HTTP/1.1 302 Found
	Location: https://auth-server.tld/authorise?response_type=code
	&client_id=6BZF3wT52E7PaIlF1luRrKM4LMfkl649
	&redirect_uri=http://client.tld/signin/redirect
	&scope=basic,contacts
	&state=84Y632oM3j

2) The user signs into the authentication server and, if they haven’t already, approves the client to access their data. The user is informed which data the client wishes to access (defined by the scope parameter). If the user has already approved the application the server will check if the scope parameter matches that of the previous request and if it doesn’t will ask the user to sign in again.

3) The authentication server redirects the user back to the client (based on the redirect_uri parameter) with an authorisation code and the anti-CSRF token in the query string

	HTTP/1.1 302 Found Location: http://client.tld/signin/redirect
	?code=Al0wQaeTYsji97oRWk2l6Y940wdca3J2
	&state=84Y632oM3j

4) The client then exchanges the authorisation code for an access token by authenticating itself with the authentication server

	POST http://auth-server.tld/access_token HTTP/1.1
	Content-Type: application/x-www-form-urlencoded
	client_id=6BZF3wT52E7PaIlF1luRrKM4LMfkl649
	&client_secret=Al0wQaeTYsji97oRWk2l6Y940wdca3J2
	&redirect_uri=http://client.tld/signin/redirect
	&code=Al0wQaeTYsji97oRWk2l6Y940wdca3J2
	&grant_type=authorization_code

5) The authorisation server will perform the following validation:

  • Check that the client_id and client_secret are valid parameters
  • Check that the [authorisation] code matches the client_id and the redirect_uri

If the parameter pass the validation checks then the authentication server will respond with the access token that the client needs to access the user’s data. The server may also include a refresh token in the response.

	HTTP/1.1 200 OK
	Content-Type: application/json;charset=UTF-8
	Cache-Control: no-store
	Pragma: no-cache
	
	{
		"access_token":"2YotnFZFEjr1zCsicMWpAA",
		"expires_in":3600,
		"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
	}

Accessing resources

Once the client has the access token it can then make requests to the resource server for the user’s data

	POST http://resource-server.tld/user/details HTTP/1.1
	Content-Type: application/x-www-form-urlencoded
	
	access_token=2YotnFZFEjr1zCsicMWpAA

Angst against OAuth

Tim Bray, a developer at Google wrote in a recent blog post that he believes:

The new technology coming down the pipe, OAuth 2 and friends, is way too hard for developers; there need to be better tools and services if we’re going to make this whole Internet thing smoother and safer.

As someone who has been working with OAuth 2.0 for almost 18 months now I disagree with Tim’s position that OAuth 2.0 is “way too hard” for developers. The web-server flow essentially is a simple two step process:

  1. A redirection from the client to the authorisation server
  2. A POST request to the authorisation server to swap the authorisation code for an access token

I find it hard to believe that those two simple steps are too much for developers to implement in their applications.

It’s true that OAuth 1.0a was a pain to implement – just take a look at Twitter’s OAuth 1.0a guide to see how complicated it is in compared to the v2.0 flow I’ve described above – however as more and more service providers offer OAuth 2.0 endpoints I believe that developers will realise how easy it is to actually implement.

Linkey, Chapter One

Alex Bilbie / / Nutshell

It’s 9am on Monday 25th June 2012 and the Linkey project is officially kicking off.

What is Linkey

Linkey is a JISC funded research project under the Access and Identity Management programme. It will run from June 2012 to May 2013.

The project will provide a detailed case study of the use of OAuth as an authorisation protocol here at the University of Lincoln. Working closely with the university Library, we will examine how the OAuth 2.0 specification can be integrated into a ‘single sign on’ environment alongside Microsoft’s Unified Access Gateway.

Our intention is to show how OAuth 2.0 can be used as part of an access and identity environment in higher education that improves the student experience by:

  1. A consistent and user centric sign-­in experience.
  2. A richer exchange of user information between applications.
  3. Easier development and implementation of new products.

Why?

A recent review of the university’s library systems and services indicated that we had around 10 core applications which provide access to over 150 other resources, all of which have different methods of authenticating users – some used LDAP to authenticate users (and so users use their network username and password) and others had their own database of users (which require a different passwords – and in some cases usernames – and every single one of these flows have a different sign in experience; some are web based with various designs, others are desktop based with a mixture of custom sign-in windows and Microsoft sign-in screens. Over 80% of user queries sent to the Library’s support email address around about problems accessing resources.

Outside of the library there are over 100 other systems and services that have visibility in the business processes across the university which also authenticate in a number of different ways.

All of these different authentication flows lead to a very inconsistent user experience and consistently for the last few years this has been highlighted in numerous student surveys.

Who?

I (Alex Bilbie) will be undertaking the majority of the work on the project. This will include researching technological solutions, engaging with end users, developing the open source OAuth 2.0 PHP server and working on the final implementation.

The principal user on the project will be Dave Masterson, Head of Electronic Library Services, who has been charged with improving the usability of our Library’s online services.

The project manager for the project will be Joss Winn, Senior Lecturer in CERD and co-ordinator of the LNCD group.

Tim Simmonds, Online Services Team Manager, will assume management and oversight of the technical implementation of both OAuth and UAG.

When?

The high level work plan is a below:

Month 1 2 3 4 5 6 7 8 9 10 11 12
Initiate project X
Community Engagement X X X X X X X X X X X X
Gather user requirements X X X X X X X X X X
Evaluate available technologies and options X X X X
Design Solution X X X
Technical development and implementation X X X X X X X
Write case study X X X X X X X X X X X
Write/submit conference paper X X X X X X
OAuth workshop  X
Project close X

You can follow the day to day activity on our Pivotal Tracker project page.

Outcomes

The anticipated outcomes of the project are:

  1. A case study of our implementation of OAuth 2.0 together with Microsoft’s UAG product. We will provide draft sections of the final case study in 12 monthly blog posts, allowing for early peer-review.
  2. Continued development of our open source OAuth 2.0 server (based on my server code), including an implementation of the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 specification and other relevant extensions to the main standard. We aim to produce a ‘drop in’ solution for OAuth 2.0, in a similar way that the SimpleSAMLphp project supports SAML implementations.
  3. A public workshop on the use of OAuth 2.0 in Further and Higher Education.
  4. A conference/journal paper, based on our case study.
  5. Expertise in the implementation of an institution-wide infrastructure for AIM.