013 - Permissions model
Purpose
This design document proposes a design for the permissions model for Monitor Space Hazards.
Context and scope
Monitor Space Hazards provides conjunction and re-entry reports and alerts to a range of users, including satellite operators and government users. Different users require access to different reports and therefore we require a permissions model to manage this. A permissions model is also needed to enable (a) management of users within each organisation by organisation admins and (b) editing of alerts by users at the UK Space Agency.
Goals and non-goals
Through this Design doc, Monitor Space Hazards aims to meet the following goals:
- Develop a permissions model which gives users access to the information and tasks they need
- Ensure the permissions model does not give users access to information or tasks they are not authorised for
- Ensure the permissions model is scalable, enabling new use cases and users to be added in future
The actual design
We have designed a permissions model which includes 6 different user types, each of which can access different content and complete different actions depending on the organisation they work for.
| Organisation type / role | Operator Organisation (e.g. Astroscale, OneWeb) | Government Organisation (e.g Cabinet Office, Defra, DFT, CAA) | Space Agency Organisation (e.g. UKSA, MOD, NSpOC) |
|---|---|---|---|
| 1. Super User (MFA) | - | - | Super User |
| 2. Approver (MFA) | - | - | Agency Approvals |
| 3. Analyst | - | - | Analyst |
| 4. Admin | Operator Admin | Government Admin | Agency Admin |
| 5. Operator | Operator | - | - |
| 6. User | Operator User | Government User | Agency User |
The 6 user types would be able to do the following:
- Superuser: Administrators of the service with access to all information and tasks
- Approver: Staff members at a Space Agency organisation with the ability to view, edit and manually send notifications for all alerts
- Analyst: Staff members at a Space Agency organisation with the ability to view all reports/alerts but no admin privileges
- Admin: Can view reports/alerts relevant for their organisation, and are able to create, view, update and delete all accounts within their organisation
- Operator: Satellite operators who can view reports/alerts relevant for their organisation and perform additional actions such as uploading ephemeris data, but have no admin privileges
- User: Can view reports/alerts relevant for their organisation, but have no additional permissions within their organisation
Importantly, both the Super User and Approver user types will require multi-factor authentication to access the service, recognising their ability to upload information to the service.
Alternatives considered
The permissions model passed through several iterations before being finalised. Discussions included: (1) whether to enable government users to view all reports/alerts, and (2) whether to enable all UK Space Agency staff members to edit and manually send notifications for all alerts or create a separate Approver user type.