Authorization Configuration Design

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.

    - id: visitors
    - id: managers
      expression: role == 'manager'
    - id: members
      expression: role == 'member'
    - id: default
        - group: visitors
          action: drop
        - group: managers
          action: accept
        - group: members
          action: accept
    - id: get_token
        - group: members
          action: drop
    - id: run_automation
        - group: members
          action: drop
    - id: see_batch
        - 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 or False 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 the see_automation and see_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:

  1. Parent application makes a POST request to /authorizations.json, sending a payload and time_in_seconds and receiving a token. The payload should be a JSON dictionary of user-defined variable values by id, e.g. {"role": "member", "organization_id": "abc123"}.
  2. Parent application redirects the user to the automation and sends the token either in a cookie named crosscompute or as a GET parameter named token. Programmatic requests can also send the token using the Authorization header as a Bearer token.
  3. 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 the see_batch permission is match, then compare the token variables and batch variables to determine whether a specific batch is accessible. If the see_automation permission is match, then render the first matching batch in the main display when display.pages > id=automation > design=input OR design=output