-
Notifications
You must be signed in to change notification settings - Fork 1
Description
We need to add a whitelist table to control access for the scenario endpoints.
The table has the scenario ID and the LHAs who have access to the scenario:
| scenarioId | lha |
|---|---|
| scenarioA_id | lha_a, lha_b |
| scenarioB_id | lha_a |
A scenario can either be:
- 'public' if there is no entry for it on the whitelist table
- 'private' if the whitelist only contains the original LHA's ID
- 'shared' if there are multiple LHAs who can access the scenario
Therefore, the LHA ID column must never be empty otherwise it becomes inaccessible to everyone but the maintenance accounts which bypass whitelist restrictions.
Maintenance accounts need to bypass the restrictions in order to fetch scenarios to simulate and update scenarios with the simulation results.
- Create the relevant SQL models in order to migrate the changes to the database
- Modify the scenario endpoints to check the whitelist before querying or returning anything
-
GET /scenarios/{scenarioId}andGET /scenarios/{scenarioId}/infectiondatashould check whether the relevant scenario has a whitelist entry and whether the requesting user belongs to an LHA on the whitelist (also check if the user is logged in) - if the user does not match the whitelist return
401 Unauthorizedor403 Forbidden-
is this security relevant info? should we return
404 Not Foundinstead so that there's no indication whether or not a scenario exists? since the user needs the ID anyways the already know this scenario should exist right? unless someone would just randomly try UUIDs? 😂
-
-
GET /scenarios/should filter its response to only contain entries which are either public (no whitelist) or private/shared with the users LHA ID in the whitelist - Add a skip condition to allow the maintenance scripts/LHA-ID to skip the whitelist check as it needs to access all scenarios to create records and simulate data
- Add
GET /scenarios/{scenarioId}/whitelist,POST /scenarios/{scenarioId}/whitelist, andDELETE /scenarios/{scenarioId}/whitelistendpoints for CRUD-operations on the whitelist- these requests should only be accessible by the scenario owner
-
or LHA admin? both?
POSTrequest should create a new entry int he whitelist table or update an existing one, the endpoint should allow to add one or multiple LHAs to the whitelistDELETErequest should delete one or multiple LHAs specified from the whitelist-
if no LHA specified: set to 'private' i.e. remove everyone but the original LHA? or delete the whole whitelist i.e. set to 'public'?
- make sure the whitelist is never empty as this would mess with the rest of the logic
-
GETshould return the current whitelist, ('private' if only one LHA), or 'public' if none is found; the get request should return401if not authorized or403if the user is not the creator/belongs to the creator LHA
-
Additional tasks that could also be moved to their own issues:
- add checks to
DELETE /scenarios/{scenarioId}andPUT /scenarios/{scenarioId}so that only the scenario creator (or its LHA admin?) and the mainentance accounts can successfully use the endpoint. Return403 Forbiddenif a user from a different LHA tries to delete or update a scenario not created by them.-
PUTshould probably only be accessed by maintenance accounts but this could change in theory if an LHA sets up their own runners for scenario simulations I guess 🤔
-