Project Plan

Project Summary

The Linkey project will provide JISC and the community with a Case Study and related technical outputs of an implementation of the OAuth 2.0 standard as part of an institution-wide strategy for Access and Identity Management 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.

One of the lasting outcomes of our JISC-funded Total Recal ‘rapid innovation’ project in 2010, was that we wrote the first (and only) OAuth 2.0 server for the CodeIgniter PHP development framework that we use. Since the Total Recal project, we’ve used OAuth 2.0 for a number of projects: Jerome,, Zendesk, Get Satisfaction, and more recently the cloud-based Orbital project.

Having been researched, developed and implemented under earlier JISC-funded projects, our OAuth 2.0 server has been formally adopted by central ICT Services, and consequently a more user centric approach to AIM is being adopted, where staff and students are gradually being presented with a consistent sign-in process, as well as given control over what services their identity is bound to and what permissions those services have.


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. Richer sharing of data between applications: A student or lecturer should be able to identify themselves to multiple applications and approve (and revoke) access to the sharing of personal data between those applications.
  2. A consistent user experience (UX): We are initially aiming for ‘consistent sign on’ rather than ‘single 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).

Anticipated Outputs and Outcomes

Output / Outcome Type

(e.g. report, publication, software, knowledge built)

Brief Description

Case Study 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.
Code Continued development of our open source OAuth 2.0 server, 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.
Workshop A public workshop on the use of OAuth 2.0 in Further and Higher Education.
Conference paper A conference/journal paper, based on our case study.
Expertise Expertise in the implementation of an institution-wide infrastructure for AIM.

Overall Approach

ICT and the Library have agreed to take the following steps to achieving our above stated objectives:

  • 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. This is the first step towards objective.
  • All web-based applications must offer a consistent looking sign-in screen based on the current design (which uses our Common Web Design[1]). This is the second step towards objective.
  • All systems must implement web-based single sign on via OAuth, SAML or ADFS, using either the Microsoft Unified Access Gateway (UAG)[2] or the OAuth server, which will include the ‘SAML 2.0 Bearer Assertion Profiles for OAuth 2.0’ specification.[3]

This is a twelve-month project, largely undertaken by Alex Bilbie, a web developer working in the central ICT Online Services Team. The work consists of research, development and a fully documented implementation of OAuth 2.0 as part of an institutional Access and Identity Management solution. This will result in a Case Study and accompanying source code, which are our main deliverable. 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 Principal Investigator/Project Manager for the project will be Joss Winn, Senior Lecturer in CERD and coordinator of the LNCD group.[4] Tim Simmonds, Online Services Team Manager, will assume management and oversight of the technical implementation of both OAuth and UAG.

Dissemination will be both informal and formal. Community engagement will be on-going throughout the project using our project blog, Twitter accounts and Github (where the code is hosted). We have demonstrated in past projects that we maintain active project websites and use social media effectively. More formal dissemination will take place through the use of Press Releases, a public workshop and the case study.

Anticipated Impact

We believe this is a distinctive project that clearly builds on previous JISC-funded projects and further development at the University of Lincoln. It offers a number of benefits to project stakeholders:

Impact Area

Anticipated Impact Description

Students and academic staff The Linkey project benefits students and staff by providing a consistent, user centric experience when signing in to services across the university. Furthermore, they will be able to clearly identify the applications they have approved, their permissions and the data that those applications have access to, offering greater oversight over personal data.
Technical staff The Linkey project will consolidate the Access and Identity Management processes at the university into a single directory of users across all applications. It offers the opportunity for technical staff to focus on the research, development and implementation of a robust ‘consistent sign-on’ infrastructure. Research into OAuth, SAML and UAG, for example, will be documented and shared with others, benefitting from peer-review via the project blog, workshops, conferences and responses to the case study. Much will be learned during the course of the project.
The University of Lincoln Improving Access and Identity Management is a strategic step towards improving the student and staff experience at Lincoln. Once implemented, it will allow the institution to respond more rapidly to changing expectations from our users and deploy a broader range of technologies more swiftly and consistently. By consolidating Access Management into two clearly delineated but joined methods (OAuth & UAG), we expect it to positively impact other processes, including the procurement of new applications, the security of data and remote working.
The University sector The case study, conference paper and workshop, will benefit colleagues from the sector by providing a number of opportunities to learn about the use of OAuth at Lincoln and consider how it could benefit their own institutions. This body of knowledge will accompany open source server code that works ‘out of the box’ and can be re-used for implementation by other HEIs.
The Public All project outputs will be publicly available for re-use, and all code from the Linkey project will be open source for use by other developers and organisations. To our knowledge (based on a question sent to the IETF OAuth mailing list), there are no existing open source implementations of the ‘SAML 2.0 Bearer Assertion Profiles for OAuth 2.0’, and our existing OAuth 2.0 server is the most complete open source solution written in PHP.

Stakeholder Analysis

Stakeholder Interest/Stake Importance
Staff and students Improved User Experience; richer sharing of data between applications. Greater oversight of academic identity. High
Technical staff Consolidation of services; efficiencies gained through re-use of previous work. Provision of new infrastructure; personal and professional development of staff. High
University of Lincoln Consolidation of services; increased agility and more rapid deployment of new and more flexible services. High
Other HEIs A case study and workshop on the use of OAuth in a HEI. Opportunities for knowledge transfer. Re-use of open source OAuth server. Medium
JISC Value for money, in terms of re-use of previous JISC-funded work. Provision of open source code for re-use by the sector. Distinctive case studies and a well-documented project website. Showcase of innovative use of new technologies. High
Public Value for money, in terms of re-use of previous JISC-funded work. Provision of open source OAuth server for re-use. Medium

Related Projects

This project has several related internal projects that are using OAuth for application authorisation, but there are no dependent projects. External to the University of Lincoln, we are not aware of any projects in the UK HE community that are actively implementing the OAuth 2.0 standard.


Unified Access Gateway is a product that we currently have little-to-no experience with as an institution so extensive research and testing will be needed to undertaken to understand it’s potential and how it can be integrated into our environment and work-flows.

As there is no open source implementation (to our knowledge) of the OAuth Assertions extension our work will rely heavily on the OAuth standards community and other contributors to help ensure that our implementation correctly follows the specification.


We assume that the project is 12 months long and will be run as a close collaboration between the Centre for Educational Research and Development (where the Project Manager works), the Library (where the Senior User works) and the Online Services Team (where the Web Developer works). This has worked well for us in the past. We have made certain technical assumptions about the intended use of OAuth 2.0 and Microsoft UAG. We assume that we will receive support from colleagues outside the project team and have secured senior support for the project to help enable this.

Risk Analysis

Risk Description

Probability (P)

1 – 5

(1 = low

 5 = high)

Severity (S)

1 – 5

(1 = low

 5 = high)

Risk Score


Detail of action to be taken

(mitigation / reduction / transfer / acceptance)

Losing staff 1 4 4 Mitigation. Assign other staff to the role. Ensure transfer of knowledge to other staff throughout the project.
Intended approach (OAuth/UAG) is not viable. 2 3 6 Reduction. Spend first part of the project designing a solution with users. Speak to vendors and OAuth community.
Doesn’t pass user acceptance tests 3 2 6 Reduction. We take an agile approach and iterate our projects regularly, working closely with users.
Significant changes to the OAuth specification 1 2 2 Acceptance. The standard has been quite stable for some time. Any changes made to the standard should affect our project positively overall, providing any dependent technologies also reflect those changes.
Changes in requirements for overall AIM architecture 2 3 6 Acceptance. The intended approach is to combine Microsoft UAG and OAuth. The Linkey project can meet its objectives regardless of changes to the overall required architecture as this is a business driven project and the outcome will still be of value to the university and sector.

Technical Development

In the Total Recal project, we released version 1 of the OAuth 2.0 server code[5] but have learned a lot since that project through integrating OAuth with other services and through our API-driven approach to development.[6] Version 2 of our OAuth server[7] is more representative of our current implementation and fully implements the latest draft (28) of the specification. Our single sign-on (SSO) service at[8] is the gateway to our current OAuth 2.0 implementation.

Most recently, the Orbital project has extended our OAuth 2.0 server to include some of the optional parts of the specification which had not been in use at Lincoln, such as refresh tokens[9] and using HTTP Authentication[10] with the client credentials flow.[11] This means that the server is now able to drop straight into a wider range of projects and services. However, many of our larger applications, such as WordPress, Exchange, Blackboard, HIP, EPrints and Sharepoint, remain disparate from one another, with no sharing of application data, except for that provided by the Active Directory.[12]

At the time of writing, the current institution-wide use of OAuth extends to Zendesk,[13] the Gateway,[14] the Staff Directory,[15] the Student Union website[16] and Posters@Lincoln.[17] Projects such as Jerome, and Orbital, as well as three 3rd year Computer Science student dissertation projects are using it, too. As stated above, our intention is to use OAuth alongside Microsoft’s Unified Access Gateway (UAG) using SAML as a bridge to OAuth via the ‘SAML 2.0 Bearer Assertion Profiles for OAuth 2.0’ specification. As such, we anticipate our implementation to look something like this:

Figure 1: Anticipated AIM process diagram


For Lincoln, a combination of OAuth and UAG is the preferred route to achieving a user-centric and consistent sign in process 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 (e.g. WordPress, EPrints).


Name of standard or specification



OAuth 2.0
SAML 2.0
PHP 5.3+
Micorsoft Forefront UAG 2010 (SP1)

Intellectual Property Rights

All project documentation, including the Case Study and blog, will be licensed under a CC-BY license. Code will continue to be licensed under an open source MIT license.

Project Resources

Project Management

This project is a mixture of research and development, largely undertaken by one person. At least half of Alex’s time will be spent undertaking research around the implementation, engaging with users and designing a solution to SSO. We hold weekly project meeting and require regularly blog posts to keep updated on this aspect of the work. Each of the team members works closely together and communication among us is easy and straightforward.

Development for the project will be run using the ‘Crystal Clear’ agile methodology, which we use on other development projects.[18] Crystal Clear is characterised by the following:

  1. Seat people close together, communicating frequently and with goodwill.
  2. Get most of the bureaucracy out of their way and let them design.
  3. Get a real user directly involved.
  4. Have a good automated regression test suite available.
  5. Produce shippable functionality early and often.

Within this environment, we practice open development,[19] using Github as a source code repository[20] and Pivotal Tracker to iteratively manage project tasks.[21] We have recently implemented an automated regression test suite and employ ‘Continuous Integration’ using the Jenkins software.[22] Such an environment will support Alex on this project by ensuring that his code is available for peer-review by colleagues and publicly available for scrutiny. Code will be constantly tested by Jenkins for quality assurance and thereby provide working code for regular user testing. Alex will work closely with users in the Library and ICT to guide the development and implementation of the SSO service.

Project Roles

Team Member Name


Contact Details

Days per week to be spent on the project

Joss Winn Project Manager 0.25
Alex Bilbie Web Developer 5.0
Tim Simmonds Technical Manger 0.125
Dave Masterson Senior User 0.125

Alex Bilbie is a developer for the Online Services Team within ICT Services and a part-time undergraduate Computer Science student, finishing his final year. He has worked on the JISC-funded JISCPress, Total Recal, Jerome and Linking You projects. He developed the university’s Common Web Design and the university’s OAuth 2.0 server. He is a contributor to the CodeIgniter PHP framework and has also contributed to the HTML5 Boilerplate framework, WordPress and the OAuth 2.0 specification. Alex was invited to talk about OAuth at the Eduserv Federated Access Management conference, November 2011.

Dave Masterson: Head of Electronic Library Services. Dave has responsibility over all technical, electronic, systems, acquisitions and cataloguing services in the Library. Dave was recently charged with improving the user experience of library applications and will act as the Principal User on the Linkey project, co-ordinating other user engagement.

Tim Simmonds: Online Services Team Manager. Tim has worked for the university for over 20 years and is in charge of all online services managed by the ICT department. He will bring this experience to the project and represent ICT Services as a Stakeholder, overseeing the implementation of the UAG and OAuth implementations.

Joss Winn: Project Manager. Joss is a Senior Lecturer in the Centre for Educational Research and Development and has been Project Manager on a number of JISC-funded projects. He will manage the Project and report to JISC and other Stakeholders. Joss joined the University in 2007 to work on the implementation of the Institutional Repository and is Co-ordinator of the LNCD group, an institution-wide group focusing on technology for education.

Programme Support

Advice and guidance on running the workshop deliverable and other effective methods of dissemination.

Detailed Project Planning

3.1    Evaluation Plan


Factor to Evaluate

Questions to Address


Measure of Success

On-going Production of case study Is the document being drafted iteratively? Is it available for comment? Does it include a number of use cases? Does it cover the full scope of the project? Are efforts being made to engage users/the community in the drafting of the document? Regularly drafts on blog. Announce drafts on mailing lists/social media. Review drafts at project meetings. The case study is published with input from the JISC AIM community. A briefing paper can be produced from the executive summary.
On-going Development of OAuth server Is the server following changes to the OAuth spec? Is the server being developed openly? Are contributions from vendors and the AIM community being solicited? Is the server being designed so that it can be used by other institutions and companines? Does the sever pass QA checks? The work is appropriately documented for implementation by other developers. Develop on Github public repository. Engage CodeIgniter and other PHP-based communities. Solicit collaboration on OAuth mailing list. Develop QA tests for Jenkins. An up-to-date, generic, open source OAuth server for PHP is available from Github. It has been openly developed and received contributions from other interested developers and organisations. It is well documented.
May 2013 Workshop Has the workshop been designed so that it is of greatest benefit to the community? Does the workshop involve both HEIs, developers and vendors? Are the outcomes of the workshop captured and, where appropriate, sustainable? Develop workshop in consultation with JISC and the AIM community. Ensure that both academic and commercial networks are informed of the event. Have case study ready to hand out at workshop. The workshop was well attended by people from both within and outside the HEI community. The case study was ready to provide to attendees. The workshop was well integrated with other JISC AIM events. The workshop led to further interest and possible collaboration between attendees.
Early 2013 Conference paper Does the paper address the interests of its intended audience? Does the paper attempt to combine the interests of HEIs, vendors and developers? Is the conference selected so as to achieve maximum impact for the project? Can the paper be developed into a refereed journal paper? Does the paper reflect the work of the project well? Identify suitable conferences within the first four months of the project. Consult JISC AIM community for related events. Solicit initial ‘peer review’ from JISC AIM community and Lincoln colleagues. The paper was accepted and presented at a high profile conference and is suited to submission to a journal.
On-going Development of expertise Is the expertise gained being appropriately embedded and disseminated to other Lincoln colleagues? Is expertise being drawn from outside Lincoln and the JISC community e.g. private sector? Is the expertise being transferred/disseminated via the project blog and other events? Ensure that other ICT staff are well informed of the project’s progress. Hold internal workshops for ICT staff to ensure they understand the findings of the project. Ensure that the project blog is regularly updated and appropriate mailing lists are kept informed of project progress. Staff at Lincoln develop expertise in Access and Identity Management issues and the implementation of OAuth and UAG-based solutions. There are regular opportunities for knowledge transfer within ICT. The project blog is regularly updated. The case study and other documentation are both informative and useful.

3.2    Quality Assurance

Output / Outcome Name

Production of case study

When will QA be carried out?

Who will carry out the QA work?

What QA methods / measures will be used?

On-going Project Manager/Web Developer Draft Case Study on project blog over the course of the project. Make available for peer-review. Include as agenda point at weekly team meetings. Ensure that is uses jargon free language, is available in accessible formats. Final version has approval from project director.

Output / Outcome Name

Development of OAuth server

When will QA be carried out?

Who will carry out the QA work?

What QA methods / measures will be used?

On-going Project Manager/Web Developer The code meets recognised QA standards and passes build tests. The code is openly available for peer-review. The code is functional and in production use at Lincoln. The code is correctly licensed for re-use.

3.3    Communication and Dissemination Plan


Dissemination Activity



Key Message

On-going Blogging Public/External and Internal Stakeholders/Project Team/Users Provide regular updates and reflections on the Orbital project. To offer general information about the progress of the project.
On-going Public Project Management Public/External and Internal Stakeholders/Project Team/Users Offer a transparent view of the running of the project and its outputs at all stages of production. (i.e. source code via Github, task management via Pivotal Tracker). We welcome peer-review and engagement at any time and recognise that we have much to learn from others.
On-going User engagement The Library and other university staff and students. To ensure that our users remain at the core of the project and committed stakeholders. So as to receive useful and representative requirements for the project. Users are at the heart of the project.
11/2012 Articles in Staff Magazine University of Lincoln staff To inform all staff at the university of Lincoln about the project and seek their feedback. We are committed to improve access and identity management at the university.
On-going Digital Infrastructure Programme networking DI and AIM communities To seek reciprocal peer-review and collaboration. The proposed use of OAuth is quite new to the HE sector and should provide a valuable case study for other institutions. We are doing innovative work that could be of value to you.
12/2012 & 06/2013 Project reports DI and AIM communities To inform the community about the work we are doing and seek peer-review and opportunities for collaboration. A summary of the project to-date.
04/2013 Conference/journal paper(s) DI and AIM communities To seek reciprocal peer-review and collaboration. Our Research and Development is of scholarly interest and undertaken with rigour.
05/2013 Reflective video DI and AIM communities, public As a way to reflect informally on lessons learned. “What we learned in a nutshell”
05/2013 Workshop DI and AIM communities To provide space and time for knowledge transfer inside and outside the sector. We value your interest in the project and would like to help you.

3.4    Exit and Embedding Plans

Project Outputs/Outcomes

Action for Take-up & Embedding

Action for Exit

Production of case study Draft case study on blog throughout project. Deliver final case study and briefing paper to JISC for community. CC-BY licensed review, available from our Institutional Repository, linked to via our project website.
Development of OAuth server On-going engagement with users and developers, both inside and outside the education sector, including vendors. Creation of Github project site to encourage re-use/forking and social engagement among developers. Publish on Github, engage other open source projects that show an interest in it. Seek advice from Software Sustainability Institute. Provide consultancy to sector and business on AIM.
Workshop Invitation to JISC community, vendors and key private companies to facilitate knowledge transfer and product awareness. Publish outcomes of workshop.
Development of expertise In-house knowledge transfer among key IT staff, good documentation, sharing of responsibilities around AIM among staff. Ensure that the local developer skills to maintain and develop the AIM infrastructure are retained. Ensure that the benefits of AIM are clear to Snr. Management. Measure the impact of Linkey wherever possible.

3.5    Sustainability Plans

Project Outputs

Why Sustainable

Scenarios for Taking Forward

Issues to Address

Development of OAuth server This will provide ‘drop in’ code for use by other institutions. Much has been learned in the process of developing the software that will be of relevance and use going forward. Publish on Github, engage other open source projects that show an interest in it. Seek advice from Software Sustainability Institute. Provide consultancy to sector and business on AIM. Ensure that the local developer skills to maintain and develop the AIM infrastructure are retained. Ensure that the benefits of AIM are clear to Snr. Management. Measure the impact of Linkey wherever possible.



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
Design solution X X
Technical development and implementation X X X X X X X
Documentation and Use Cases X X X 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
Close project X

Project start date: 05/06/12

Project completion date: 04/6/13

Duration: 12 months



WORKPACKAGE 1: Initiate project


Objective: Set up project, recruit staff




Complete project documentation 04/07/12 Project Plan, Workpackages, Budget, Web template


Set up project website 04/07/12


Recruit Web Developer 04/07/12 Full-time staff for project




WORKPACKAGE 2: Community Engagement


Objective: A mixture of dissemination, user-feedback and peer-review. This is on-going and multi-various




Set up meetings with users 04/07/12 Regular meetings with users with meeting notes posted on the blog


Start blogging 04/07/12 Regular blog posts on


On-going face-to-face conversations with users On-going Regular meetings with users with meeting notes posted on the blog


Identify conference/journals to submit paper to 01/13


Run workshop at Lincoln 05/13


Measure impact of engagement On-going Blog posts, analytics, speaking invites, project enquiries, etc.


Announce project to OAuth community 04/07/12 Message on IETF mailing list, blog posts


Contact vendors On-going Establish relationships with key vendors and users of key technologies.


Engagement with open source community (codeigniter, PHP, OAuth) On-going Source code available on Github, blog posts and tutorials on blogs




WORKPACKAGE 3: Gather user requirements


Objective: To understand our users’ requirements and, with them, design an appropriate solution for AIM.




Gather user stories On-going Meetings with users


Assess current state of AIM On-going Review of current systems, video/document examples of what needs improving.


On-going face-to-face communication with users On-going Meetings with users




WORKPACKAGE 4: Evaluate available technologies and options. 

Objective: To provide context to our project and ensure that the design of our solution meets best practice.




Research UAG 09/12 Blog posts documenting research


Research SAML 09/12 Blog posts documenting research


Research OAuth 2 09/12 Blog posts documenting research




WORKPACKAGE 5: Design solution






Design OAuth 2 server library and framework integrations 10/12 A blog post and accompanying drawings and documentation.


Design improved authentication interfaces 10/12 A blog post and accompanying drawings and documentation.




WORKPACKAGE 6: Technical development and implementation






Re-architect existing OAuth 2 server code 03/13 Open source code with documentation.


Implement bearer spec in OAuth 2 server code 03/13 Open source code with documentation.


Implement improved authentication interfaces 03/13 Open source code with documentation.




WORKPACKAGE 7: Documentation and user cases






Document code On-going Inline code comments, developer documentation.


Document user case studies On-going Documented in blog posts and with code.





WORKPACKAGE 8: Write case study






Draft blog posts On-going Blog posts


Draft case study 04/13 A draft document


Final case study 05/13 A final document.





WORKPACKAGE 9: Write/submit conference paper






Identify paper topic 12/13


Identify conference 01/13


Complete/submit paper 05/13




WORKPACKAGE 10: OAuth workshop






Plan workshop 01/13


Deliver workshop 05/13




WORKPACKAGE 11: Close project






Submit final report and budget report 06/13 A final report and budget.


Publish Case Study 06/13 A case study


Ensure sustainability plans are in place 06/13





Members of Project Team:

Name Role
Joss Winn Project Manager
Alex Bilbie Web Developer
Tim Simmonds Technical Manager
Dave Masterson Senior User

[8] An actual example of our current OAuth sign-in application can be seen at:

[12] An illustration of our existing AIM process can be seen at:

[21] e.g. Our tracker for the Orbital project

Leave a Reply

Your email address will not be published.