Home/Blog

Federated SSO for Australian Institutions

Blog / Luke Horvat / October 13, 2016

Like many educational institutions in Australia, Deakin University provides a range of cloud services to its staff and students, such as DeakinSync, DeakinPeople, DeakinAir, and DeakinTalent. In order to let users conveniently sign in to these disparate applications using a single set of credentials (i.e. one unique identity), it maintains a Single Sign-On (SSO) service.

For a recent in-house DSTIL project, I successfully integrated Deakin University’s SSO service into a small Web application, enabling easy sign-in for my fellow university colleagues. This blog post details some of the core concepts learnt along the way, as well as helpful tips for aspiring application developers.

Shibboleth

Shibboleth is a popular open source software package for managing SSO across/within organizational boundaries, and it powers Deakin University’s SSO service.

Fig.1 – Shibboleth logo

With Shibboleth, an organisation sets up an “identity provider”, which is essentially a centralised system responsible for managing user identities and performing authentication/authorisation. Then, whenever the organisation develops a new application that requires SSO, they simply configure it as a compatible “service provider”. The aforementioned DeakinSync, for example, is a Shibboleth service provider that interacts with Deakin’s identity provider in order to provide SSO.

Fig.2 – Entities

Rapid Connect

Deakin University is a member of the Australian Access Federation (AAF), meaning its Shibboleth SSO service can be freely utilised by users belonging to other federated organizations. So, for example, given that Monash University is also a participating AAF member, its users can (in theory) sign in to services provided by Deakin.

Fig.3 – AAF logo

Given that Shibboleth is a complex beast and setting up a newly-developed application as a service provider can be quite time-consuming, AAF offers a helpful Rapid Connect service to its member organisations. Essentially, Rapid Connect lets you forgo setting up a Shibboleth service provider as long as your application’s auth endpoint can parse incoming JSON Web Tokens (JWT). It does this by acting as a kind of “proxy” service provider on your application’s behalf, coordinating all interactions with the identity provider and sending a minimal JWT payload of user information to your application when a successful sign-in occurs. A much more suitable abstraction for application developers!

JWT

When registering an application with AAF Rapid Connect, one must specify the location of the auth endpoint (aka the “Callback URL”) capable of receiving JWTs.

Fig.4 – Service Registration

JWT is simply a JSON-based open standard for constructing tokens that assert one or more “claims”, as detailed in the Rapid Connect developer guide. So the onus is on the receiver – in this case, your application’s auth endpoint – to validate the claims contained within.

With that said, I recommend structuring your endpoint in the follow manner:

  1. Extract signed JWT from request body.
  2. Decode signed JWT. (You’ll want to use a third-party software package for this; personally, I had success with jwt-simple for Node.js.)
  3. Perform JWT claim validations recommended by AAF.
  4. Perform any custom JWT validations specific to your application. (For example, you may want to grant access to Deakin University staff only, and not students.)
  5. Extract user information from JWT and store it in a session cookie.
  6. Redirect user to back the application entry point i.e. sign-in successful!

Example Code

As shown, Rapid Connect is a convenient abstraction over Shibboleth that facilitates quick integration of SSO functionality into applications developed for AAF member organisations. If you are considering using it, check out some of the helpful open source software packages I built throughout my maiden journey with Rapid Connect, listed below: