How to Manage High Assurance Flows

High assurance flows use authentication policies to enforce additional restrictions to API access of flows and their runs. This includes limiting access to potentially sensitive data in a flow (including its definition) and runs (including their current state and run logs).

Note

High assurance flows require a High Assurance or HIPAA Business Associate Agreement (BAA) subscription tier.

Prerequisites

Before you can create a high assurance flow, you will need:

  • A high assurance or BAA subscription

  • A high assurance authentication policy

For general information about the high assurance tier at Globus, see:

Creating a High Assurance Flow

You can create a high assurance flow by assigning a high assurance authentication policy and HA subscription when creating a flow. It is not possible to convert a flow to or from HA after creation.

If you are authoring flow definitions that interact with other high assurance resources (such as GCS collections or Compute endpoints) or handle sensitive data, review the High Assurance Flows authoring guide for additional information.

Using the Globus Web App

Login to the Globus Web App (app.globus.org). Open the Flows page from the navigation menu, select the Deploy a Flow tab, and then select the Deploy Flow button.

Screenshot of Deploy a Flow page

Fill out the flow creation form. In addition to the standard fields (title, definition, input schema), you’ll need to provide:

  • Subscription ID: Your high assurance subscription ID

  • Authentication Policy ID: The ID of a high assurance authentication policy

Screenshot of flow creation form with authentication policy field

Select the Deploy Flow button to create your high assurance flow.

Using the Globus CLI

You can create a high assurance flow using the Globus CLI:

$ globus flows create "My HA Flow" flow_definition.json \
  --input-schema input_schema.json \
  --subscription-id <SUBSCRIPTION_ID> \
  --authentication-policy-id <POLICY_ID>

where <SUBSCRIPTION_ID> is your high assurance subscription ID and <POLICY_ID> is the authentication policy ID from the previous step.

Tip

Once a flow is created with an authentication policy, it becomes a high assurance flow and cannot be downgraded to a standard flow. If you need a standard version of the flow, you must create a new flow without the authentication policy.

Working with HA Flows and Runs

Users interacting with a high assurance flow will need to meet additional authentication requirements specified by its authentication policy.

High assurance flows use the authentication policy to authorize all read access to sensitive information on the flow and its runs, as well as all write access to the flow.

Accessing the Flow

When a user attempts to access a high assurance flow or its runs, Flows checks to see whether any of their identities have a role on the flow or run (including via group membership), and then whether any such identities have met the criteria specified by the authentication policy.

If the user has a role on the flow, but doesn’t meet the criteria specified in the authentication policy (for example, due to a session timeout), they will receive a prompt to reauthenticate.

Screenshot of GARE reauthentication prompt

The user must reauthenticate with an identity and method that meets the requirements specified in the authentication policy.

Tip

This prompt is driven by a specific API error type called a Globus Auth Requirements Error (GARE). Handling GAREs is an important consideration for any application that may need to support users granting additional consent or reauthenticating to satisfy an authentication policy.

Viewing Flows and Runs

Because listing resources—whether through the Flows API or via Globus Search—may return multiple resources with different (and possibly mutually incompatible) authentication policies, Flows instead ensures that some field values are omitted when listing HA flows and runs.

  • HA flows omit the values of their definition and input_schema fields

  • HA runs omit the value of their details field

Users can still view this information by accessing the specific flow or run directly (after satisfying the authentication policy).

Understanding Restrictions

High assurance flows apply additional restrictions beyond the standard flow limits.

The Authentication Policy Cannot Be Removed

The authentication policy cannot be removed from an HA flow, but it may replaced with another high assurance authentication policy by the flow owner or administrators.

A user replacing an authentication policy must be able to satisfy the requirements of both the old and new policies.

The Subscription Must Be High Assurance

The subscription assigned to a high assurance flow can only be changed to another high assurance subscription.

HA Flow Roles Prohibit "Public" and "Authenticated Users" Principals

Roles on high assurance flows cannot be assigned to the special principals all_authenticated_users or public. All role assignments must be to specific users or groups.

For more information about flow roles, see Permissions.

No Access to a Flow or Runs is Permitted if a Policy is Deleted

If a flow’s authentication policy is deleted from the Globus Auth service, Flows will no longer be able to use it to enforce access controls on its associated flows and runs. In this case, access will be denied to all flows and runs that were associated with that policy until a new high assurance policy is assigned to the flow.

To restore access to a flow in this state, you must have an owner or administrator role on the flow, and you must be a member of the HA subscription group assigned to the flow. Users that meet this criteria can update the flow with a new high assurance policy using the Globus CLI or directly via the Flows API.

Before assigning an authentication policy to a flow, consider who should manage the authentication policy as well as whether it should be used for more than one resource (flows, collections, endpoints, etc.).

Flow Author Responsibilities

Important

While authentication policies help restrict access to flows and their runs, flow authors are ultimately responsible for the flow’s behavior and for properly handling any potentially sensitive data.

Authentication policies control who can access the flow, but they cannot prevent logical errors in flow definitions or guarantee proper handling of sensitive data within the flow execution.