We are thinking of ways to selectively grant and restrict access to specific automations and batches, in cases where a user’s privileges are determined by a parent application.
Here is the proposed design for the authorization configuration of an automation. The structure is based on iptables and pyramid.authentication.
authorization:
groups:
- id: visitors
- id: managers
expression: role == 'manager'
- id: members
expression: role == 'member'
permissions:
- id: default
rules:
- group: visitors
action: drop
- group: managers
action: accept
- group: members
action: accept
- id: get_token
rules:
- group: members
action: drop
- id: run_automation
rules:
- group: members
action: drop
- id: see_batch
rules:
- group: members
action: match
- id: see_root
- id: see_automation
- id: see_run
-
Groups are custom segments of users defined using expressions. An expression evaluates to either
True
orFalse
and contains variables that are pre-defined and/or stored in tokens. Pre-defined variables start with an underscore, e.g._address
for ip address. -
Permissions correspond to ways that users can interact with the automation:
default, get_token, see_root, see_automation, see_batch, see_run, run_automation
. -
Action can be one of
accept, match, reject, drop
.-
accept
: Grant specified permission to group. -
match
: Grant specified permission if token variable values match batch variable values (only used for thesee_automation
andsee_batch
permissions). -
reject
: Reject requests for the specified permission. -
drop
: Ignore requests for the specified permission, i.e. pretend as if the specified permission does not exist.
-
Here is the proposed authorization procedure:
- Parent application makes a POST request to
/authorizations.json
, sending apayload
andtime_in_seconds
and receiving atoken
. Thepayload
should be a JSON dictionary of user-defined variable values by id, e.g.{"role": "member", "organization_id": "abc123"}
. - Parent application redirects the user to the automation and sends the token either in a cookie named
crosscompute
or as a GET parameter namedtoken
. Programmatic requests can also send the token using theAuthorization
header as aBearer
token. - User sends an automation request. Child automation retrieves the token’s payload to load variable values by id, then evaluates expressions to decide the user’s eligible groups and finally checks permissions, starting with
default
, to determine whether to grant, reject or ignore requests. If thesee_batch
permission ismatch
, then compare the token variables and batch variables to determine whether a specificbatch
is accessible. If thesee_automation
permission ismatch
, then render the first matching batch in the main display whendisplay.pages > id=automation > design=input OR design=output