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) | Space Agency Organisation (e.g. UKSA, MOD, NSpOC) | Regulator Organisation (e.g. CAA) |
|---|---|---|---|---|
| 1. Super User (MFA) | - | - | Super User | - |
| 2. Approver (MFA) | - | - | Agency Approver | - |
| 3. Analyst | - | - | Agency Analyst | - |
| 4. Admin | Operator Admin | Government Admin | Agency Admin | Regulator Admin |
| 5. Operator | Satellite Operator | - | - | - |
| 6. User | Operator User | Government User | Agency User | Regulator 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 + all lower priviledge permissions
- Analyst: Staff members at a Space Agency organisation with the ability to view/edit all reports/alerts + all lower priviledge permissions
- Admin: Can view reports/alerts relevant for their organisation, and are able to create, view, update and delete all accounts within their organisation + all lower priviledge permissions
- 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 + all lower priviledge permissions
- User: Can view reports/alerts relevant for their organisation, but have no additional permissions within their organisation
Note: users in public sector organisations (e.g. government and regulator organisations) will be able to see all UK-licensed objects and relevant events. Operator Organisations will be restricted to only viewing information relevant to their assets.
Note: 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.