Implementing OAuth 2.0

One of the lasting outcomes of our Total Recal ‘rapid innovation’ project in 2010, was that Alex Bilbie wrote the first (and only) OAuth 2.0 server for the CodeIgniter PHP development framework that we use. Since then, he’s been refining it and with every new project, we’ve been using it as part of our API-driven approach to development. As far as we know, the use of the OAuth 2.0 specification, which should be finalised at a forthcoming IETF meeting, is not yet being used by any other university in the UK. There are a few examples of OAuth revision A in use, but OAuth 2.0 is a major revision currently in its 23rd draft.

As a result of his work, Alex was invited to talk about OAuth 2.0 at Eduserv’s Federated Access Management conference last year.

OAuth 2.0

View more presentations by Alex Bilbie

Nick Jackson gave the same presentation at the Dev8D conference a couple of weeks ago.

Since Total Recal, we’ve used OAuth 2.0 for Jerome, data.lincoln.ac.uk, Zendesk, Get Satisfaction, and more recently Orbital and now ON Course.  We’re at the stage where our ‘single sign on’ domain https://sso.lincoln.ac.uk is the gateway to our OAuth 2.0 implementation and it will soon be running on two servers for redundancy. In short, due to various JISC projects helping pave the way, it has been formally adopted by central ICT Services, and staff and students are gradually being given control over what services their identity is bound to and what permissions those services have.

Single Sign On at Lincoln
Single Sign On at Lincoln

The work Nick is doing on the Orbital project is extending Alex’s OAuth 2.0 server to include some of the optional parts of the specification which we’ve not been using at Lincoln, such as refresh tokens and using HTTP Authentication with the client credentials flow. This means that the server is able to drop straight in to a wider range of projects and services.

Recently, JISC published a call for project proposal around Access and Identity Management (AIM), which I am starting to write a bid for. Appendix E1 states:

JISC is particularly interested in seeing innovative and new uses for OAuth. Bids should show how this technology brings benefits to the community and can help address institutional requirements within research, teaching and learning, work based learning, administration and Business Community Engagement.

In Total Recal, we released version 1 of the server code but have learned a lot since that project through integrating OAuth with other services. Version 2 of our OAuth server is more representative of our current implementation and fully implements the latest draft (23) of the specification.

However, this is what access and identity management currently looks like:

SSO Current Situation
SSO Current Situation (click the image)

At the moment, the most widespread use of the OAuth server is Zendesk, our ICT and Estates online support service. Projects such as Jerome, Orbital, and ON Course, as well as three 3rd year Computer Science student dissertation projects are using it, too. The plan is to use OAuth alongside Microsoft’s Unified Access Gateway (UAG), which can talk SAML to OAuth via the OAuth SAML 2.0 specification. Here’s what we intend to do:

SSO Ideal Situation
SSO Ideal Situation (click image)

The primary driver for this is the ‘student experience’ and it cuts three ways:

  1. Richer sharing of data between applications: A student or lecturer should be able to identity themselves to multiple applications and approve access to the sharing of personal data between those applications.
  2. A consistent user experience: What we’re aiming for at first is not strictly ‘single sign on’, but rather ‘consistent sign on’, where the user is presented with a consistent UX when signing into disparate applications.
  3. Rapid deployment: New applications that we develop or purchase should be easier to implement, plugging into either OAuth or the UAG and immediately benefiting from 1) and 2).

Following a recent meeting between ICT and the Library, we agreed to take the following steps:

  1. 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. This is the first step towards step (3).
  2. All web-based applications must offer a consistent looking sign-in screen based on the sso.lincoln.ac.uk design (which uses the Common Web Design). This is the second step towards (3).
  3. All systems must implement web-based single sign on via OAuth, SAML or ADFS and they will be sent to either UAG or the OAuth/SAML server.

The library are going to investigate to what extent we can do (2) with their applications such as Horizon and EPrints, and from then on, systems that are purchased or updated must do (3). It also makes sense to look at EPrints and WordPress in the short-term as applications that can use OAuth.

Two of the outputs we’ll propose to JISC are a case study of this work, as well as further development of the open source server Alex and Nick have been developing including an implementation of the OAuth SAML specification that we’ll share. Like our related work on staff profiles, the need to get access and identity right is becoming increasingly apparent as staff and students become accustomed to the way access and identity works elsewhere on the web. For Lincoln, a combination of OAuth and UAG is the preferred route to achieving consistent sign on across all applications, bridging both the internally facing business applications managed by ICT (e.g. Sharepoint, Exchange, Blackboard) and the more outward facing academic and social applications such as those developed and run by the Library and the Centre for Educational Research and Development.

Orbital: A proposed Managing Research Data project

Following my usual tradition, I am dutifully posting a bid document that I submitted today to JISC’s Managing Research Data Programme. As you might already know, I do this in an attempt to open up the process of bid writing a bit more, in what is normally a competitive environment. I also hope that it might attract some interest from and possible future collaboration with other people in the university sector, whether we are successful in winning funding or not. We’ve been pretty successful with our bids over the last couple of years, too, and have received good feedback from JISC on the quality of our bids, so it seems like the decent thing to share good practice.

Our proposed project is called Orbital because we’re intending to build services for managing research data that ‘orbit’ around Nucleus, the data store we built during the Total Recal and Jerome projects. The bid was a pretty easy one to write, to be honest. Everything felt right as soon as I read the call documentation because I could see a way of re-using and further developing the work we’ve been doing since I joined the university in 2007. Of course, we’ve set ourselves some new challenges with this project and much work needs to be done in all phases of the project, but having the experience of building web services around large institutional data sets, gives me the confidence that we can tackle what is a really important issue for us – for any university: managing a growing body of research data. It’s also a project that takes me back to my roots, having joined the university to work on our Institutional Repository project. Prior to that I was an Archivist at the BFI National Film and Television Archive and Project Manager for the development of Amnesty International’s Digital Asset Management system. It was good to revisit the the whole digital archiving domain again and I even re-discovered a blog I kept in 2006 while on JISC’s week-long Digital Preservation Training Programme.

Although the bid has been sent off now, and who knows whether it will be funded or not, the process of writing the bid has been really useful. I had planned to spend much of July drafting a journal paper but seeing the call, switched into bid writing mode. Writing bids regularly, I try to get something out of them, despite knowing that they may not be funded. The idea of retrospectively viewing unfunded bids as a waste of time would depress the hell out of me and so I try to approach it as a reflective process, where I talk with colleagues about what we’ve done, where were are now and where we want to go with our work. Through writing this bid, it became really clear how the work we’ve been doing on other projects has brought us to the point where we have a good team of people who have developed a very modern, extensible and flexible technical framework which we can deploy in a number of domains, including managing research data. It’s all in the bid, so I won’t repeat it here, but it’s something we should be proud of.

I think that one of the things that good developers do is identify and/or build the tools they need to do their job effectively. That’s what we’ve been doing with WordPress, the Common Web Design, OAuth, Nucleus, data dot lincoln,  the Jerome discovery tool and the Linking You toolkit, so that now we have the skills and the tools to tackle future work more efficiently and have fun, too. There’s nothing that kills the fun of development more than having to work with crap tools.