[Feature]: Add Role based access control to running workflows - inputstep decorator

[Mark90]

Contact Details

markmdev_51242 in the discord channel (see readme).

What should we build?

Add the authorize_callback parameter to the @inputstep decorator.

See #782 for original requirements and #837 for how this was implemented on the @workflow decorator.

• Think of a solution where the form generator is aware whether or not the user can execute the step.
  • the submit button is disabled if the user has no rights
• Or show a standard "not authorized" form to the user, if they have no rights

[hanstrompert]

Adding the following diagram made by @eenblam, just to record the current state of thinking.

[eenblam]

Workflow Authorization Requirements

Certain orch-core decorators will accept an authorization callback of type type Authorizer = Callable[OIDCUserModel, bool], which returns True when the input user is authorized, otherwise False.

A table (above) is available for comparing possible configuration states with the policy that will be enforced.

@workflow

The @workflow decorator must support an optional auth: Authorizer parameter. auth will be used to determine the authorization of a user to start, resume, or retry the workflow from a failed step.

If auth is omitted, the workflow is authorized for any logged in user.

The @workflow decorator must support an optional retry_auth: Authorizer parameter. retry_auth will be used to determine the authorization of a user to start, resume, or retry the workflow from a failed step.

If retry_auth is omitted, then auth is used to authorize.

(This does not percolate past an @inputstep that specifies resume_auth or retry_auth.)

Examples:

• auth=None, retry_auth=None: any user may run the workflow.
• auth=A, retry_auth=B: users authorized by A may start the workflow. Users authorized by B may retry on failure.
  • Example: starting the workflow is a decision that must be made by a product owner. Retrying can be made by an on-call member of the operations team.
• auth=None, retry_auth=B: any user can start the workflow, but only users authorized by B may retry on failure.

@inputstep

The @inputstep decorator must support an optional resume_auth: Authorizer parameter. resume_auth will be used to determine the authorization of a user to resume the workflow from this step, or retry subsequent failed steps.

If resume_auth is omitted, then the workflow's auth will be used.

The @workflow decorator must support an optional retry_auth: Authorizer parameter. retry_auth will be used to determine the authorization of a user to start, resume, or retry the workflow from a failed step.

If retry_auth is omitted, then resume_auth is used to authorize retries. If resume_auth is also omitted, then the workflow’s retry_auth is checked, and then the workflow’s auth.

(See table linked at top for examples.)
In summary:

• A workflow establishes auth for starting, resuming, or retrying.
• The workflow can also establish retry_auth, which will override auth for retries.
  • An inputstep can override the existing auth with resume_auth and the existing retry_auth with its own retry_auth.
• Subsequent inputsteps can do the same, but any None will not overwrite a previous not-None.

Examples

Assume we have the following function that can be used to create callbacks:

def allow_roles(*roles) -> Callable[OIDCUserModel|None, bool]:
    def f(user: OIDCUserModel) -> bool:
        if is_admin(user):  # custom function
            return True
        for role in roles:
            if has_role(user, role):  # relative to your authorization provider
                return True
        return False

    return f

We can now construct a variety of authorization policies.

Rubber Stamp Model

Suppose we have a workflow W that needs to pause on inputstep approval for approval from finance. Ops (and only ops) should be able to start the workflow and retry any failed steps. Finance (and only finance) should be able to resume at the input step.

@workflow("An expensive workflow", auth=allow_roles("ops"))
def W(...):
    return begin >> A >> ... >> notify_finance >> approval >> ... >> Z

@inputstep("Approval", resume_auth=allow_roles("finance"), retry_auth=allow_roles("ops"))
def approval(...):
    ....

Hand-off Model

Suppose we have two teams, Dev and Platform, and a long workflow W that should be handed off to Platform at step approval.

Dev can start the workflow and retry steps prior to S. Once step S is reached, Platform (and only Platform) can resume the workflow and retry later failed steps.

@workflow("An expensive workflow", auth=allow_roles("dev"))
def W(...):
    return begin >> A >> ... >> notify_platform >> handoff >> ... >> Z

@inputstep("Hand-off", resume_auth=allow_roles("platform"))
def handoff(...):
    ....

Notice that default behaviors let us ignore retry_auth arguments in both decorators.

Restricted Retries Model

Suppose we have a workflow that anyone can run, but with steps that should only be retried by users with certain backend access.

@workflow("A workflow for any user", retry_auth=allow_roles("admin"))
def W(...):
    return begin >> A >> ... >> S >> ... >> Z

Note that we could specify auth=allow_roles("user") if helpful, or we can omit auth to fail open to any logged in user.