Authorization Configuration Design

1

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 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
2

The proposed configuration format will enable the features related to progressive disclosure, conditional permissions, payment authorizations:

  • Progressive Disclosure: Show different templates based on variable values (i.e. choose your own adventure).
    • In the configuration below, which-x will show first, then x-small if x <= 90 or x-large if x > 90.
  • Conditional Permissions: Let automations behave differently based on variable values.
    • In the configuration below, the automation can run for free if x <= 90.
    • It will also run if the person has an active payment in one of the following authorization groups: the automation referenced by AUTOMATION-SLUG, the automations by the user referenced by USER-SLUG or the automations by the organization referenced by ORGANIZATION-SLUG.
  • Payment Authorizations: Link payments to authorization groups.
input:
  variables:
    - id: x
  templates:
    - id: which-x
    - id: x-small
      expression: x <= 90
    - id: x-large
authorization:
  groups:
    - expression: x <= 90
      permissions:
        - id: run_automation
    - configuration:
        automations.AUTOMATION-SLUG.role:
          name: member
          status: active
      permissions:
        - id: run_automation
    - configuration:
        users.USER-SLUG.role:
          name: member
          status: active
      permissions:
        - id: run_automation
    - configuration:
        organizations.ORGANIZATION-SLUG.role:
          name: member
          status: active
      permissions:
        - id: run_automation
payment:
  groups:
    - configuration:
        automations.AUTOMATION-SLUG.role:
          name: member
          status: active
      amount: 120
      currency: usd
      period: year
      account: YOUR-ACCOUNT-URI