Skip to content

Add Whitelist to Scenario Endpoints #16

@NXXR

Description

@NXXR

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} 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 🤔

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions