008 - User Management
Purpose
Taking a lead from Google’s engineering culture this is a design doc. It is a relatively informal document that details a high-level implementation strategy and key design decisions, with particular emphasis on the trade-offs considered in those decisions.
This document tackles the problem of user management in the Monitor Space Hazards service. It is an experiment in the potential use of these artefacts.
Context and scope
Monitor Space Hazards ties together common needs of Satellite Operators, Orbital Analysts, the UK Space Regulator (the Civil Aviation Authority), other government departments and the UK Space Agency (UKSA). The shared needs centre around notifications regarding conjunction and re-entry events and the sharing of refined UK-based Orbital Analysis on them.
The high-level workflow for Monitor Space Hazards is:
- Ingest a data feed for Conjunction Data Messages (CDM) or Trajectory and Impact Predictions (TIPs) from Space-Track. Monitor Space Hazards’ Space-Track permissions only allows it to ingest CDMs and TIPs for UK objects, so no filtering of these is needed at an ingestion level
- Group together CDMs and TIPs and raise conjunction and re-entry events for further Orbital Analysis
- Share the further Orbital Analysis with users
Therefore, multiple organisations will be using the Monitor Space Hazards service and viewing different information about each event. It is considered that each organisation will be best placed to understand their own joiners, leavers and movers within their organisation.
Goal and non-goals
The goal of this design doc is to articulate a User Management design sufficient for the beta phase of Monitor Space Hazards.
Unpacking this a little gives the following goals:
- Focus on delivery of core high-value Monitor Space Hazards features over ancillary processes
- Minimise the user management overhead placed on the UKSA
- Streamline the user experience for accessing Monitor Space Hazards as much as possible
- Enforce the principle of least privilege for users
- Keep user management abstracted away from core features so that its implementation can be swapped out in the future
And the following non-goals:
- Building a custom user management solution for Monitor Space Hazards
The actual design
There are multiple organisations, each with their own users, that are interacting with each other and Monitor Space Hazards. This includes:
- Orbital Analysts at the UK Space Agency, who need to be able to ingest data from and upload data to the service
- Other staff at the UK Space Agency, who need to be able to view all information on the service and make some additions to alerts
- UK satellite operators, who need access to data for their own satellites
- Other UK government departments, such as the Civil Aviation Authority, Ministry of Defence and Cabinet Office, who need to understand about threats and hazards in space
- International partners, who benefit from the UK’s re-entry preedictions
Given the system context above and the goals for user management, the following user management use cases are proposed. See Design Doc 013 - Permissions Model for more detail on different user types.
| Use Case 1 | Onboarding a new organisation |
|---|---|
| Actor | Superuser |
| Overview | The UKSA is responsible for onboarding new organisations. This will involve off-system assurance of the domain associated with the organisation, and the creation of a single user at that organisation with an “Admin” role. The trigger for this use case is an “Superuser” clicking a GOV.UK Design System button stating “Invite a new organisation”. At MVP, users and organisations will be on boarded by manually adding emails to the database of users and setting account permissions in this database manually. |
| Use Case 2 | Onboarding a user |
|---|---|
| Actor | Organisation Admin |
| Overview | Each organisation has at least one “Admin”. This “Admin” then bears responsibility for creating, updating and deleting users within the organisation and domain they are responsible for. The trigger for this use case is an “Admin” clicking a GOV.UK Design System button stating “Invite a new team member” Monitor Space Hazards validates the new user’s email address domain matches the “Admin's” email address and sends an email to validate the entire address. This implies user accounts have a state model, proposed states are:
|
| Use Case 3 | Inactivating a user |
|---|---|
| Actor | Organisation Admin/Superuser |
| Overview | Organisation Admins may inactivate users in their organisation due to an off-system event such as someone leaving an organisation. Superusers may do so for all users, regardless of organisation. At MVP, this would require the Organisation Admin or Superuser to manually remove the user from an organisation. |
| Use Case 4 | Inactivating an organisation |
|---|---|
| Actor | Superuser |
| Overview | Superusers may inactivate an organisation due to an off-system event such as an organisation leaving Monitor Space Hazards. At MVP, this would require the Superuser to manually remove all users from an organisation from the system. |
| Use Case 5 | User Management Audit |
|---|---|
| Actor | Monitor Space Hazards |
| Overview | All user management events, including all of the above use cases, will be audited. There will be a design decision on whether to implement event sourcing in Monitor Space Hazards, in which case auditing will come as part of that decision. |
Importantly, Superusers who have the ability to make many of these user management changes will require Multi-Factor Authentication (MFA) to access their accounts.
APIs
We have made available a public API for user management - this is documented in our OpenAPI specification in the users section.
Data storage
The Monitor Space Hazards database stores user records in the following data schema:
.
The definitions below were used in dbdiagram.io to generate the above diagram:
Table organizations as O {
id uuid [pk, increment]
name varchar
email_domain varchar
}
Enum user_statuses {
unvalidated
active
inactive
}
Table users as U {
id uuid [pk, increment] // auto-increment
email varchar
toc_accepted_at timestamp
is_active boolean
is_verified boolean
role character
notification_settings json
first_name varchar
last_name varchar
phone_number varchar
notification_thresholds json
account_details_confirmed_at timestamp
organization_id uuid
}
Ref: U.organization_id > O.id
Code and pseudocode
There are no novel algorithms to describe in code or pseudocode for this design.
Degree of constraint
Monitor Space Hazards is a greenfield development so is relatively free of constraint.
Alternatives considered
The main area for alternative considerations is authentication, where we considered introducing Multi-Factor Authentication (MFA) for all users. MFA requires two or more independent ways to identify a user. Examples include codes generated from smartphones, captcha tests, fingerprints, voice biometrics, facial recognition and so on. MFA is good against most hacks, but comes with its own pitfalls such as lost phones, SIM cards etc.
It was decided that information presented on Monitor Space Hazards is not sufficiently sensitive to require MFA for all users. However, MFA is required for most users, including Superusers, with the ability to make changes to the service. However, Orbital analysts will not have access to mobile phones while working so MFA involving smartphones cannot be the default for all user groups.
Cross-cutting concerns
The design will conform with the cross-cutting concerns, such as observability, privacy and security, decided and documented elsewhere for Monitor Space Hazards.