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. --- - [x] 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}` and `GET /scenarios/{scenarioId}/infectiondata` should 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 Unauthorized` or `403 Forbidden` - > *is this security relevant info? should we return `404 Not Found` instead 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`, and `DELETE /scenarios/{scenarioId}/whitelist` endpoints for CRUD-operations on the whitelist - these requests should only be accessible by the scenario owner - > *or LHA admin? both?* - `POST` request 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 whitelist - `DELETE` request 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 - `GET` should return the current whitelist, ('private' if only one LHA), or 'public' if none is found; the get request should return `401` if not authorized or `403` if 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}` and `PUT /scenarios/{scenarioId}` so that only the scenario creator (or its LHA admin?) and the mainentance accounts can successfully use the endpoint. Return `403 Forbidden` if a user from a different LHA tries to delete or update a scenario not created by them. - > *`PUT` should 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* 🤔