OERu/Planning/2016 Action plan/MVP Tech 01/Task 04 SSO
Contents
Outputs
This work builds on previously described SSO requirements. Our underlying intention is to create
- A prototype technology solution which can allow users (educators and learners) of the MVP to access all relevant aspects of the Minimum Viable Platform with a single login, using a single set of credentials (at minimum, an email address and a password), as well as a mechanism for storing those credentials and allowing users the ability to alter them (e.g. change email addresses and/or passwords) without administrative involvement, i.e. "self-service".
- A distinction between infrastructure components and examplar technologies in the Minimum Viable Platform.
The former consists of crucial technologies that the OERu will build and for which we will provide ongoing maintenance as they are crucial to the working of the Minimum Viable Product. The latter are exemplary implementations of technologies for which member institutions are likely to want to substitute their own replacement. These exemplars are intended to demonstrate the viability of the overall collection of technologies, filling a gap, or "boot-strapping" the solution. We encourage institutions looking for such components to consider these exemplars as they are all open source software. The OERu does not commit to supporting these exemplars in the medium to longer term.
Criteria for success
- The ability for an arbitrary user to create an account in our exemplar system, set (and change) credentials (including email and password)
- After entering their credentials successfully one time, an authenticated user can access their own accounts on all of the Minimum Viable Platform systems for which authentication is required.
An additional (unintentional, but perhaps compelling) benefit of this is that other external partners could opt to allow authentication via this SSO service for their own services.
Task 1: Identify the components of the SSO System
The components for the Single Sign-On System include those required for operations, user management, and testing.
Operations
The normal workflow for Single Sign-On works as follows:
- a user creates (or has an administrator create for her) a set of credentials (identifier and secret, usually an email and a password) which only she knows via a website interface
- the user then enters those credentials securely into a web application (login form) via an encrypted (HTTPS) internet transaction.
- Alternative flow: the user is given the option of requesting a password reset, which is provided via email. This assumes that the user's access to their email is privileged
- the web interface passes the entered credentials to the integrated Identity Provider which in turn queries
Directory Service
We originally considered employing a Directory service in which to store user credentials, which can be automatically queried to confirm that a computer user using an OERu service is whom they purport to be. Using a generic solution, like OpenLDAP (we setup a test instance), with an open source web-based administrative interface called phpLdapAdmin, however we determined that this was like attempting to tap in a brass tack with a sledge-hammer. Perhaps one day such an industrial strength solution might be warranted (if, for example, we wanted to maintain complex group and institutional associations for users), but it's overkill for the MVP.
Instead, we are currently using the in-built user storage systems of a Drupal 7 website. The advantages of this are that:
- we understand the Drupal CMS,
- it's a time-tested, hardened, relatively secure technology (if kept up-to-date, which we do pro-actively),
- we can easily store (in a MySQL database) and backup the user data,
- we can use the website's CMS capabilities to provide well-presented, clear instructions on the services people can access through this, and most importantly,
- it makes it easy to provide a "self-service" interface for users to maintain their own details like email addresses and passwords. Drupal is good at doing things like
- verifying that an email address is correct,
- making sure people specify strong passwords when changing them, and
- it has a good system for allowing people to recover their password if they forget it.
You can have a look at the preliminary OERu Directory, keeping in mind that it is not yet fully functional.
Identity Provider
A Directory service is not sufficient for providing Single Sign-On. To provide a complete solution, we also require an Identity Provider, a mechanism to provide proof of identity in a secure way to various applications which want to work with users whose identity is reliably known (i.e. by having entered their user credentials, at least an email address and password, but sometimes also a username).
The choice of Identity Provider dictates which identity protocols (with names like Shibboleth, CAS, OpenID, WS-Federation, OAuth, or Persona) we can support. Most interesting web applications, like those making up the other components of the OERu Minimum Viable Platform, support one or more of these common protocols as an alternative to their native (in-built) identity provision and authentication mechanisms. They support these mechanisms for precisely the situation we are in: where their application is being used in conjunction with other complementary applications, by a large user-base, under the banner of an umbrella organisation.
Due to its many supported identity protocols and broad development community, we have selected an Identity Provider using the Security Assertion Markup Language (SAML), and specifically a well regarded, open source implementation called SimpleSAMLphp.
Service Provider
A Service Provider (or an SP) is a website or application that accepts authorisation and authentication details from an external Identity Provider (IdP). Imagine logging into an IdP and then going to a SP that recognises the IdP you're logged into: if you're arriving at the SP for the first time, you might be asked to "approve" the SP having access to your credentials. If you do so, the SP will then create a user on its system which is linked to your IdP record. If you've been there before and have already approved the SP, it should automatically recognise your valid IdP session and you should find yourself already logged in as the linked user.
The tricky part about SPs and linking them to IdP records is that every system has (often very subtly) different ways of representing key user information. Just about all websites will store a unique identifier like a username or, more commonly, an email address. They will also store a "secret", usually a password. This latter one usually is not stored by the IdP - a "transformation" of it is stored (created by performing a mathematical calculation called a "hashing function" on the actual user password and storing the result, which is guaranteed to be irreversible). Because the SP defers to the IdP's password, usually you just get a random password or placeholder to ensure that the SP's data integrity requirements are maintained (the password's just a dummy - it's not used).
The SP might also want a Name (perhaps differentiating between First and Last names), maybe a phone number, a website address, an "avatar" (usually an image used to represent a user, often a user-selected photograph). The SP has to define the "metadata" that they require from the IdP when passing along the user's session data, and how that data maps from the IdP's systems into the SP. This can be fraught with complexity.
Adding further to the complexity, there's also the matter of handling updates, such as when the user changes her email address, or name, or other fields. Triggering an update of SP systems from the IdP can be problematic. Also, problematic is disabling the ability to adjust these relevant parameters on the SP's inbuilt account settings... if a user is able to change his email address on the SP, but not on the IdP, it can rapidly lead to a massive metadata snarl, where accounts become unlinked, and there is no good way to relink them.
Finally, there's the complication of having SPs that are incorporated into a Single Sign-On environment after the service already has users - how does one link an existing user account with an IdP account? Ensuring that everyone's identity and privacy is preserved in the process can be very tricky.
Website Security
A crucial but often overlooked component of secure online activities is Secure Sockets Layer (SSL) protocol which uses secure certificates (randomly generated strings of letters and numbers) to encrypt traffic between a user's computer (more precisely, the web browser running on their computer) and a website on the Internet.
The SSL system is typically provided by an open source library called OpenSSL, and the secure certificates were, until recently, acquired through a costly and cumbersome process which usually required identity and background checks of certificate holders by SSL certificate providers to ensure that the people receiving a certificate were, in fact, the relevant party. More recently, the process has been substantially streamlined by an open consortium of organisations in an effort to increase the prevalence of SSL (delivered via HyperText Transfer Protocol over TLS, or HTTPS, represented by the "lock" icon in the "location" or "address bar" in most web browsers) on the Internet, and now the Let's Encrypt project makes it possible to securely acquire certificates at no cost, while providing sufficient protection against organisational identity fraud.
For this project, all of our public-facing encryption is being provided using Let's Encrypt certificates.
