Controlling Access

Web input permissions are evaluated independent of flow and run permissions.

Web input permissions are granted by explicitly specifying principals in a CreateWebInput state. The roles cannot be changed once a run is started, so the flow author must pay close attention when defining roles in the CreateWebInput state.

Access Levels

A user’s access to a web input is determined by their explicitly assigned role:

Viewer

A viewer may see that a web input exists, the content of the web input, and the identities of the groups/users with the respondent role.

Respondent

A respondent may do everything that a viewer may do and also submit a response to the web input. + If multiple respondents are assigned (either directly or through a Globus group), any one of them may independently submit a response, thereby closing the web input.

A user with no explicit role assigned to them is considered unauthorized. They are not able to respond to, view, or see the existence of a web input, even if they manage the associated flow or started the associated run.

See Web Input Roles for a full capability matrix.

Specifying Principals

Viewer and Respondent roles are assigned in the CreateWebInput state.

Consider for example, a state with the following definition:

{
  "CreateApprovalRequest": {
    "Type": "CreateWebInput",
    "Parameters": {
      "InputType": "Selection",
      "Options": "...omitted options...",
      "Context": "...omitted context...",
      "RespondentUrns": [
        "urn:globus:auth:identity:00000000-1111-2222-3333-44444444444", (1)
        "urn:globus:auth:identity:55555555-6666-7777-8888-99999999999"  (1)
      ],
      "ViewerUrns": [
        "urn:globus:groups:id:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"     (2)
      ]
    },
    "ResultPath": "$.web_input",
    "Next": "WaitForApproval"
  }
}

  1. Either of these two individuals will be allowed to respond to the web input.

  2. Any member of this Globus group (a managed collection of users) will be allowed to view, but not respond to, the web input.

Limits and Requirements

  • A web input must have at least 1 respondent.

  • A web input may have at most 16 respondents and 16 viewers.

  • A web input’s roles cannot be modified once it has been opened.

Examples

Each of the following examples represent isolated chunks of a CreateWebInput state in a flow definition. For complete examples, see State Examples.

Globus Identity UUIDs may be accessed from the Globus CLI with:

globus get-identities <user-email>
{
  "RespondentUrns": [
    "urn:globus:auth:identity:user-uuid-here",
    "urn:globus:auth:identity:another-user-uuid"
  ]
}

Globus Group UUIDs may be accessed from the Globus Web App.

{
  "RespondentUrns": [
    "urn:globus:groups:id:group-uuid-here"
  ]
}

Similar to any state parameter, ViewerUrns and RespondentUrns may also be evaluated dynamically using expression syntax.

Using this, the respondent list may be built from run context values such as the runner’s identity.

{
  "RespondentUrns.=": "[`$._context.user_id`]"
}

Expressions may contain static strings, allowing for compositions of dynamic values (the runner’s UUID) and static values (a pre-selected group).

{
  "RespondentUrns.=": "['urn:globus:groups:id:group-uuid-here', `$._context.user_id`]"
}