jemnery
commented
8 months ago Initial hypothesis:
Authentication
- All MoJ staff have (or can get) an O365 / Azure Active Directory account ("@justice" login)
- MFA is enabled for these accounts
- There is already a joiners, movers and leavers process for AAD, so DP would not need to implement and support JML
- The DP team would not need to support user accounts (forgotten passwords etc.) as there is already a service desk function for this
- AAD is supported as an SSO mechanism for a wide range of products
- There is a very good chance users will already be logged into AAD in their browser (for the Intranet, SharePoint etc. etc.)
- AAD is so business critical it is unlikely to be replaced
=> We will use Azure Active Directory to authenticate and identify users
Cons:
- External (guest) access could be tricky
Authorisation
- While AAD does support groups, this is not reliably implemented or supported in our instance
- We have little confidence we will be give permission to manipulate AAD groups via GraphAPI in the production AAD tenant
- Being given permission to manipulate AAD via GraphAPI may expose too many permissions to the DP, and present too much of a risk
- Using directory groups for data product permissions could be clunky. For example would it be two AAD groups per product? (Read and manage?) Potentially more?
=> We will use a third party / custom built middleware solution for authorisation - i.e. user groups and roles within the data platform
There may more discussion to be had around selecting this solution, although let's try Auth0 first as it's not a custom build from scratch and some team members are already familiar with it.
As @julialawrence points out, Auth0 is configurable with Terraform.
Cons:
- Users sometimes change their name, and their AAD email changes. It may be necessary to manually support these changes if we are creating an entity relationship store between data products and @justice identities
- Depending on the solution, we may have to support and maintain the "roles" middleware (availability, backups, upgrades, issues)
- There will be no simple way to flag staff who have left. While those users will be unable to authenticate, we will be displaying product ownership (etc) linked to users who no longer exist. (However this could be considered a problem for data product owners)
User Story
As a user and platform developer I need/want/expect to have an identity service which works for our use case So that
Value / Purpose
Do we want to use Azure AD? Do we want to use OAuth? Do we need some middleware which maps an authenticated user to levels of access to data products?
eg Murdo is authenticated with Azure AD by the control panel Control panel requests Murdo's data access levels
Useful Contacts
No response
User Types
All users
Hypothesis
Proposal
AAD + Auth0. (more)
Additional Information
No response
Definition of Done