ADR-023: Use Standard SSO Architecture
Status
✅ Accepted
Context
Operations Engineering team manages several Third Party Services and also how access is managed to these services.
Historically, the process for managing access to these services has been through manual invitations.
Over the years, some of these tools and services have evolved, adopting Single Sign-On (SSO) as a method of access.
SSO offers great benefits in terms of security, ease of use for users and decreasing the administrative overhead of managing access to these services - but can still be a complex process to implement.
Where SSO has been implemented, this has typically been as an adhoc basis, with each service having its own SSO implementation.
Problems
The process has operated well, but over time, the number of tools and the disparate implementations of SSO has made the process more complex and difficult to manage.
Problem - Using Social Connections Inappropriately
Social connections are connections where anyone can have an account with the Identity Provider (IdP), such as GitHub, Facebook, Twitter etc.
Using social connections can lead to risks, since they provide no authorisation of the user and so the process depends on the Third Party Service to authorise the user either by configuration or customisation of the SSO process within the Third Party Service or a component of the SSO process.
This has been implemented correctly in most cases such as with:
- AWS SSO where we use a Auth0 Post Login Script to authorise that the user is a member of an approved Ministry of Justice GitHub Organisation.
- Docker SSO where Docker itself authorises the user against pre-defined email domains.
However, in some cases, such as PagerDuty, we had implemented SSO using GitHub as the IdP, which is a social connection, and did not configure any additional authentication checks. This means that anyone with a GitHub account could authenticate to the MoJ PagerDuty Account. This has now been rectified.
Problem - Lack of Visibility
Our SSO implementations suffered from a lack of visibility. This has made it difficult to understand how access is managed across the estate and identify any potential risks.
For example, some tools, such as PagerDuty, only allow the Account Owner to see and configure SSO settings. This lack of visibility leads to assumptions that SSO is configured correctly, but no way to verify this.
Another example is AWS SSO, where this was only partially managed by Operations Engineering and the team did not have visibility of the Post Login Script that actually authenticated the user.
Problem - Lack of Consistency
The way SSO has been implemented has been inconsistent across the estate. This has made it difficult to assess risks and implement a secure process across all of our services.
Options
1. Do nothing
Pros
- No work to do.
Cons
- Doesn’t address the emerging problems.
- Potential security risks that are hard to identify.
2. Remove SSO
Pros
- No security risks associated with SSO.
Cons
- Introduces new risks associated with manual process.
- Increases administrative burdens with managing Third Party Services.
3. Use Standard SSO Architecture
Pros
- Reduces security risks associated with SSO by decreasing complexities and increasing visibility and consistency through standardisation.
- Continues to provide the benefits of SSO for users and administrators.
Cons
- Require changes to existing SSO implementations.
Decision
We are going to implement option 3 (Use Standard SSO Architecture).
This option addresses the emerging problems.
This solution allows us to continue to provide the benefits of SSO for users and administrators, while reducing the security risks associated with SSO by decreasing complexities and increasing visibility and consistency through standardisation.
The standard SSO architecture will use MoJ Enterprise Identity Providers (IdP) so authentication and authorisation of users is done by the IdP, minimising the complexity of implementing SSO for each Third Party Service.
Currently, the MoJ have two primary Enterprise IdPs: Google Workspace and Microsoft.
Most tools will only integreate with one IdP, so we will also use Auth0 as an Identity Broker to allow us to integrate with multiple IdPs. This ensures our solutions can meet current and future requirements.