High Assurance Flows

Important

Shared Responsibility for High Assurance Flows

Globus is responsible for securing the Flows service design, development, and infrastructure. Globus cannot prevent logical errors in flow definitions or guarantee the security of customer-managed resources.

Flow authors are solely responsible for:

  • Ensuring flow definitions handle sensitive data appropriately

  • Securing customer-managed action providers

  • Testing workflows thoroughly before processing sensitive information in production

Overview

Organizations can utilize High Assurance (HA) flows in workflows that handle protected information. For more information on the additional security controls for this type of data, please refer to the High Assurance Overview. HA flows can only be created under the High Assurance or HIPAA Business Associate Agreement (BAA) subscription tier.

This guide provides the necessary domain knowledge for securely developing and operating a high assurance flow, which includes authentication policy requirements, compatible action providers, and common pitfalls to avoid.

Authentication Policies

High assurance flows require a high assurance authentication policy and an HA subscription on creation. The authentication policy will be used to enforce additional restrictions when accessing potentially sensitive data in a flow and its runs.

For more information about authentication policies, see Authentication Policies.

Authentication Policy Enforcement

A flow’s authentication policy is enforced on all direct Flows API access to a flow and its runs.

High assurance flows and runs will still appear in lists of resources returned by the Flows API and Search indices, but with potentially sensitive field values omitted. These include:

  • The flow’s definition and input_schema fields

  • A run’s details field

All other fields on a flow and its runs should not contain potentially sensitive data.

Restrictions and Limitations

High assurance flows apply additional restrictions to the standard flow limits:

  • An authentication policy cannot be added to a standard flow after creation (i.e., standard flows cannot be upgraded to high assurance later)

  • An authentication policy may be modified on a high-assurance flow, but it cannot be removed (i.e., high assurance flows cannot be downgraded later)

  • High assurance flows do not allow roles assigned to special principals such as public or all_authenticated_users (role assignments must be to specific users or groups)

See Permissions for more information about flow roles.

Authoring Flow Definitions

When authoring HA flow definitions, you can use visibility controls to limit access to sensitive data within the flow.

See Protecting Secrets for detailed information on these mechanisms.

Warning

The _private prefix and __Private_Parameters cannot protect PHI or other classes of sensitive data. These mechanisms only limit visibility in certain contexts and do not provide compliance-grade protection. Use authentication policies and proper flow design to protect sensitive data.

HA Action Providers

Many Globus action providers support high assurance. This includes:

Globus Transfer:

Globus Compute:

Other Action Providers

Customer-operated action providers—as well as Globus-operated action providers that are not listed above—should not be used to handle data that requires high assurance.

If you must use action providers that are not eligible for high assurance, evaluate:

  • What data will be passed to the action provider

  • Whether the action provider’s security controls are sufficient

  • Whether you trust the action provider operator

Tips and Precautions

Carefully Consider Authentication Policy Timeouts

High assurance authentication policies provide an authentication assurance timeout setting. Short authentication policy timeouts can pose operational challenges, for instance requiring users to re-authenticate during normal operations, or causing interruptions to long-running processes on session expiration. Carefully consider timeout values for resources to appropriately balance security with operational needs.

Deleted Authentication Policies

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 on all enforced operations (see When Policies are Enforced above) until a new high-assurance policy is assigned to the flow.

In order 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. (This is currently possible via the Globus CLI as well as 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).

Avoid Policy Restrictions that Exclude All Users with Flow Roles

Authentication policies can be used to apply domain restrictions for access to flow and run resources, while flow roles control who can view, run, or manage the flow. Problems can occur when an authentication policy’s restrictions exclude users who have roles on the flow.

For example:

  • A flow’s authentication policy restricts access to users from @campus.edu

  • The flow owner is last_name@cloudprovider.com

In this case, the owner may not be able to access their flow—even if they have a linked campus.edu identity—if their campus.edu identity does not have a role on the flow.

In this situation, access can be restored by updating the authentication policy in the Globus Auth service, or deleting it (allowing reassignment of a new authentication policy to the flow, as mentioned in the preceding section).

Flow Definition Errors

Flow definition errors can expose sensitive data. Common mistakes include:

  • Referencing _private fields in action parameters without including the field name in __Private_Parameters

  • Passing sensitive data to non-HA action providers

  • Insufficiently handling potentially sensitive data that may be returned from action providers, including within the content of an error response

See Validating Flow Definitions for information on detecting structural errors before deployment.

Important

Flow validation can help identify issues within a flow definition, but cannot validate all possible states or all field types, and will not detect logical errors in how sensitive data is handled within a flow definition. Ensure that you have carefully considered all of the ways in which your flow could be run including potential data returned from action providers and ensure your handling is appropriate.