Torq role-based access control (RBAC) architecture

Terms and definitions

Torq Organization is a logical entity provided to an organization subscribing to Torq.

Torq Workspace is a unit of compartmentalization of various hyperautomation resources (see below) inside the Torq Organization. Each organization may have one or more workspaces serving different purposes. All workspaces within an organization are segregated and decentralized, meaning there are no hierarchical or other relationships between different workspaces. Each workspace owns and contains resources of various types. Resources can be shared explicitly between workspaces. Resource access within each workspace is governed by RBAC scopes, which are aggregated to user roles for management (see below).
The most common uses for different workspaces are:

Segregation of activities for different teams in an enterprise organization
Segregation between development, staging, and production environments for automation
Segregation between different geographies in a large distributed organization
Segregation between different customers for Managed Security Services Providers (MSSPs) or Managed Services Providers (MSPs)

RBAC Scopes, defined per workspace, govern the ability of a particular user or API client to perform specific operations on specific resources. Each scope is evaluated separately in each workspace. The list of available scopes can be found in our documentation. As new functionality is added to the product, new scopes are created.

User Roles, defined per workspace, are aggregations of scopes within the relevant workspace that allow users assigned to the role to perform specific tasks. Every workspace has a set of predefined user roles, with the option to define customized roles.

SSO Claim Mapping Rules, defined per workspace, are ordered directives used when a user logs in to a Torq workspace using Single Sign-On with an organizational Identity Provider (IdP). These rules define which claims provided by SSO should associate a user role with the relevant user. The claims may pertain to a persistent user property, such as Group Membership in an IdP, or to a transient property, such as the user's location or device.

Workspace Resources are various persistent or transient components of Torq configuration and activity contained within specific workspaces (see below).

Resources segregation inside a Torq organization

As mentioned, different workspace resources are housed within workspaces created within a Torq organization. The sharing functionality (explained below) enables the explicit sharing of specific resource types across multiple workspaces, controlled by role-based access control permissions.

The decision to use workspaces as the unit of compartmentalization in Torq RBAC was made for the following reasons:

It provides sustainability for high-end enterprises with a growing number of automated use cases.

It offers simplicity and manageability.

Note

Existing out-of-the-box roles can be expanded upon request with custom roles that can be defined for each workspace. These custom roles can be created by combining different scopes from the existing roles (contact Torq support).

The diagram below illustrates an example of a Torq organization consisting of multiple workspaces, each containing distinct resources. Some resources are shared among multiple workspaces:

Workspace resources contained within each workspace may vary, but generally, they can be categorized as follows:

Step integrations

Trigger integrations

Workflows

Custom steps

Global variables

Workspace variables

Activity and audit logs

User permissions (specifically set or claim mappings based on the organizational IdP)

Step runners

API keys

Note

The mapping of User → Workspace → Role can be done either on an individual user level (not recommended for enterprise environments) or based on organizational SSO Claims.
For larger organizations, support for multiple organizational IdPs is available for different workspaces upon request.

Sharing Resources Between Workspaces

Sharing resources between workspaces within the organization is done through explicit per-resource operations. The ability to share resources is governed by RBAC scopes and is intended to be performed by workspace owners. During the sharing process, administrators can select target workspaces from those where they have a role. Workspaces that the administrator is not entitled to access will not be shown. Once a resource is shared from a source workspace to a target workspace, it must be accepted by an administrator in the target workspace. Until it is explicitly accepted, the sharing remains pending.

Sharing Trigger Integrations

When a trigger integration is shared between workspaces, any event received by this integration will be delivered to each of the workspaces. Different workflows with different triggers can be attached to the shared trigger integration in different workspaces, allowing for different workflows to be executed in response to a delivered event.

Sharing Step Integrations

All the settings and credentials of step integrations are shared between the source and target workspaces. They can be used in the steps of any workflows running in the target workspaces.