Performing Actions as Different Users

The RunAs property of an Action state can be used to control the identity associated with executing the action. In most cases, it will be appropriate to have the action invoked as the same identity that invoked the flow. This is the default behavior, so no value for RunAs is needed to get this behavior. However, other scenarios may require a single flow execution to invoke various actions using different identities or roles. The RunAs property of the Action state provides two additional types of roles that can be specified:

  • Flow: When the value is Flow, the action will be invoked as the identity of the flow itself. Because every flow is registered with the Globus Auth system so that it can authenticate requests to be run, it also has a unique identity in Globus Auth. This identity can be used to invoke other actions. Thus, once the flow is deployed, the Globus Auth identity of the flow is known, and can be configured in the authorization state of various actions for permission. To help with this form of configuration, the information provided by a flow using the command globus flows list or globus flows show includes two properties which help identity the flow. The first is principal_urn which provides the URN form of the identity for the flow which is used by many actions and other Globus services to specify identities. The other property is globus_auth_username which is another common method of naming a Globus Auth identity.

  • An arbitrary "role name" can also be specified as in "RunAs": "AdminUser". The identity for this role will be determined by an additional Globus Auth access token which is passed into the flow at run-time as part of the initial state. The flows service will use this token when invoking the action and so the action will see the request as if coming from the user associated with this token. We describe how these role-specific tokens are passed next.

Note

When a flow is run, the identity of the running user is determined by examining the token passed on the header of the HTTP request, and, as described in the next section, other tokens may be passed in the body of the request. In either case, the Flows service will validate the token by interacting with the Globus Auth service. These interactions with Globus Auth require additional time when a flow is being started. To help alleviate this overhead, the Flows service will retain (cache) results from token validity checks for up to 30 seconds. That is, if the same token is presented more than once within 30 seconds, the results from the previous check will be reused.

Thus, if a user should request that a token’s validity be rescinded, it is possible that use of the token may be considered valid for up to 30 seconds after the time the user rescinds the token’s validity.

Providing Role-Specific Tokens

When RunAs specifies a role name, corresponding tokens must be generated and provided to the flow at run-time. The necessary information to generate any Globus Auth token is the name of the scope to which the token should be generated. So that generated tokens are as specific as possible, the flows service creates a separate scope for each role which appears as part of a RunAs property. These scope strings are present in the flow description under the property globus_auth_scopes_by_RunAs. This will be a JSON object with the property names matching the roles named in RunAs and the values being the Globus Auth scope string. For example, if roles named Admin and Curator were present in the flow definition, the flow description would contain an object like:

{
  "Admin": "<Globus Auth Scope String for Admin>",
  "Curator": "Globus Auth Scope String for Curator>"
}

When invoking the flow (e.g. via globus flows start) the flow input would be required to contain the access tokens for each of the roles in a similar JSON object called _tokens as follows:

{
  "_tokens": {
    "Admin": "<Globus Auth access token for Admin>",
    "Curator": "Globus Auth access token for Curator>"
  }
}
Note

If the author of a flow provides an input_schema for their flow, the schema should specify that the _tokens property should be present with this structure. Otherwise, the Flows service will reject the input prior to running the flow.

The method for generating the required tokens is outside the scope of this document. The approach will use of the Globus Auth API and typically the Globus SDK. In particular, the section on obtaining tokens is a good starting point.