[Feature]: Add Role based access control to running workflows - update decorators

[srichmond]

Refinement of ticket after discussion on 11-2:

Requirements:

• Ability to assign privileges per group

• Ability to check privileges halfway a workflow

• Make it possible to check authorization at each input type step

  • like suspend, callback input steps (iow when a user/proces changes the workflow into running state)

• Dropped requirement: ability to change the minimal rights in the UI. This should be a handled by the auth implementation of the application

Suggested solution

• Extend the stepdecorator to call an optional function, which is performing the isAllowed function by the attribute workflow_name, workflow_step_name (optional) and user. If this function returns true the workflow (step) can be executed.
  • Update the @update, @inputstep and @workflow decorators to include the isAllowed function.

In other tickets:

• extend the graphql calls for populating the Start dropdown menu items, to include a state flag (eg isAllowed bool) to rendering the workflow item in normal or disabled state.
  [Feature]: Add Role based access control to running workflows - update StartOptions endpoint #821
• extend the graphql calls for populating the Tasks dropdown menu items, to include a state flag (eg isAllowed bool) to rendering the workflow item in normal or disabled state.
  [Feature]: Add Role based access control to running workflows - update task dropdown endpoint #822

---

Contact Details

srichmond@es.net

What should we build?

We would like to restrict access to running workflows to role based access control.

This should be pluggable such that a user can integrate with their own selected auth solution.

Relevant pseudo code

SURF ticket details https://git.ia.surfsara.nl/netdev/automation/projects/orchestrator/-/issues/2173

Summary

At the moment the task page has restricted access, while some to the workflows could be run/inspected by anybody, as the risk is minimal to none. Therefore it would be nice to be specific on defining execution rights per wf/task.
The new task button requires the access to the /orchestrator/processes/create/task. By adding an extra field to the task or workflow DB record, a minimal authorization level (MAL) can be specified.

• /orchestrator/processes/create/task/no_risk
• /orchestrator/processes/create/task/low_risk
• /orchestrator/processes/create/task/medium_risk
• /orchestrator/processes/create/task/major_risk
• /orchestrator/processes/create/task/service_affecting
• /orchestrator/processes/create/task/admin_only

By default all workflows and tasks are medium_risk.
When populating the new task dropdown, the user scope is matched with the MAL, so only allowed tasks are shown.

• add MAL field to the workflows table in coreDB
  • consider an extra field active/inactive per workflow?
  • remove column deleted_at

DB view of workflows

• add endpoint to change the MAL per workflow/task in the FE (Metadata pages), only allow valid fields (ENUM) --> ticket to be specced

• add logic that validates in the BE that requested workflow/task is allowed to be executed by the user based on the added field in the workflows table.
• Filter the new task dropdown with the valid task matching the users profile

[spinoshi]

Would be nice if we could have steps that require higher privileges to be executed. In case certain workflows/tasks span over multiple teams.

[hanstrompert]

Please finish the workflow role based access control, and create additional issue(s) for the remaining work. Link them with the Relationships field on the child issues.