Posts tagged Federated identity

Last night I took part in the Life, Identity, and Everything Google developer chat with Tim Bray and Breno de Madeiros.

Tim Bray is the Developer Advocate, and Breno de Madeiros is the tech lead, in the group at Google that does authentication and authorization APIs; specifically, those involving OAuth and OpenID. Breno also has his name on the front of a few of the OAuth RFCs. We’re going to talk for a VERY few (less than 10) minutes on why OAuth is a good idea, and a couple of things we’re working on right now to help do away with passwords. After that, ask us anything.

Here is the video of the chat:

To summarise the event they said that Google are committed to OAuth 2.0 and OpenID. They intend on all Google APIs supporting OAuth 2.0 and they believe it has helped developers develop for Android because support for the OAuth dance is baked into the Android APIs making it very simple to integrate with it.

They also feel that Mozilla Persona is a promising (but complicated) protocol; however they feel that on mobile devices it will cause problems in terms of the user flow.

I asked two questions which Tim and Breno answered:

”What do you think the future of OAuth is? Eran Hammer publicly quit as the editor and claiming the v2.0 specification is “more complex, less interoperable, less useful, more incomplete, and most importantly, less secure”. Will there be OAuth 3?”

and

“Could a ./well-known/oauth file published at each providers endpoint help with interoperability? This file would describe their implementation responds with json or text, which grants are supported, etc”

It has been a busy few weeks lately culminating in a work trip to the USA last week. This trip was quite beneficial as, when one is stuck on a plane for 9 hours each way, or completely disconnected from the world 8300ft up the Colorado Rockies in a 1970s cabin with no phone signal, TV or Internet it allows for lots of thinking.

I’ve come up with a list of things that I want to achieve for Linkey by the end of Semester 1 (end of January ’13):

  • Complete the first draft of a case study looking at institutional uses of OAuth.
  • Invite our program manager, Chris Brown, for a site visit and spend the day looking over the case study and planning the last few months of the project.
  • Formally release the code I have been working on, including documentation, unit tests and tutorials.
  • Look at developing a .well-known standard for describing OAuth endpoints and enabling discovery (more on this in a future post).
  • Work with my colleagues in ICT to start implementing a joint OAuth and Microsoft UAG web single sign-on implementation.

I’ve been asked to work with the Orbital team to try and develop an authentication endpoint that will allow University of Lincoln staff and Siemens staff to securely sign-in to applications that have been developed by that project, but with each member of staff using their own institutional/company credentials.

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.