Skip to content
This repository was archived by the owner on Sep 6, 2021. It is now read-only.

moj noms apvs 0320 single sign on

Jump to bottom
Thomas Swann edited this page Nov 14, 2016 · 1 revision

Single Sign On

Author(s) - Tom Swann

Contents

Introduction

MoJ Digital have developed a Single Sign On (SSO) application for use accross different MoJ digital services including, for example, Prison Visit Booking.

It was developed to overcome the problems (for both the business and users) inherent with developing different login solutions for every individual service.

This is applicable to the internal users of the APVS solution, as they are the same set of users who currently use the Prison Vist Booking staff-facing app.

How Does It Work?

Ministry of Justice Sign On is an OAuth based single sign on component designed to authorise staff access to multiple applications with a single account. This is increasingly a need as MoJ move away from a small number of monolithic applications to a large number of primarily web-based applications.

User authentication is via email & password.

Structure

  • Organisation
    • Team
      • User

A Team is a member of an Organsation and organisations are a hierarchical tree, represented canonically as . seperated strings.

For example, For example Pentonville prison is represented as pentonville.prisons.noms.moj.

Apps also have an owning organisation. This is used to limit their visibility within the hierarchy.

For example: an app owned by noms.moj can be seen within the pentonville.prisons.noms.moj organisation, but not within hmcts.moj. It naturally follows that permissions to access an app can only be granted to teams within the app's organisational hierarchy.

Only organisation admins (currently users with a super_admin flag set) are able to create and manage apps, teams, and permissions by teams to access apps.

Permissions

All permissions are managed at team level. Members of a team may be marked as admins, in which case they will be able to add or remove other users from that team. Users are added by email address, and will receive an invitation email which prompts them to set a password the first time they are invited.

A team can have permissions to one or more applications, and each permission has an associated set of roles. Those roles are a subset (maybe empty) of the roles defined against the application. A User is authorised to access an applications if they are a member of one or more teams with permissions to access that application.

Limitations

Signon does not currently integrate with any 3rd party identity providers (for example active directory servers), however that is a natural future direction as MoJ move to a single strong user identity.

Requirements

The first step required is to create a new App. This is a request to the Organisational team.

We must provide:

  • Name: Identify the app to users, so it should be friendly. Multiple environments are supported by including the environment in the name. E.g. Assisted Prison Visits Scheme (dev)
  • Roles: Zero or more roles which make sense for our app
  • Redirect URI: Sign on will redirect users to this URI after successful OAuth authorisation
  • Service URI (optional): Takes the user to our app from within the SSO service if they click the app name. Uses the redirect URI if not provided.

Integration

To authenticate users on the APVS app, implement the authorisation code OAuth flow using Signon as the OAuth provider. In summary:

  • Redirect the user to https://www.signon.dsd.io/oauth/authorize, including the app id

  • The user will be prompted to login if required.

  • If they are authorised to access the APVS app they will be redirected to the 'Redirect URI' which we specified

  • The APVS app then exchanges the supplied 'authorisation code' for an 'access token'. Using this OAuth access token, we make a request for the user's details calling GET /api/user_details. This call returns the following JSON data:

Example JSON response data from GET /api/user_details:

{
 "id": 42,
 "email": "[email protected]",
 "first_name": "Joe",
 "last_name": "Bloggs",
 "permissions": [
   { "organisation": "digital.moj", "roles": [ "reporting" ] }
 ],
 "links": {
   "profile": "https://www.signon.dsd.io/profile",
   "logout": "https://www.signon.dsd.io/users/sign_out"
 }
}

This response is the used to determine what level of access the user should be granted.

Our app should link to the supplied profile URL, from where the user can edit their password, etc.

In order that the user is also logged out of Signon when they log out of our app, AVPS should redirect the user to the supplied logout URL after logging them out of APVS. We may provide a redirect_to URL as a query parameter, in which case Signon will redirect the user back to this page after they have been signed out. Otherwise they will be shown a Signon login page.

Conclusion

Links

Clone this wiki locally