Skip to main content

Authorization

This page explains the management of Fine-Grained Access Control for DAS (Authz v2).

caution
  • Skip this page only if it is not enabled for your tenant.

  • To enable Fine-Grained Access Control for DAS (Authz v2) for your tenant, write an email to support@styra.com.

Styra DAS provides robust, extensible and fine-grained authorization mechanisms for easy management of access control over the workspace. Implemented on top of Open Policy Agent (OPA), DAS allows Role-based Access Control (RBAC) configuration of permissions for users, API tokens, and SSO claims over the entire workspace or underlying resources, such as systems and stacks.

For more information on how to configure an API token to have the System Owner role for a DAS System utilizing the API, see the Knowledge Base documentation.

Create and Manage DAS Subjects

This section explains how to create and manage DAS subjects.

Configure Authorization

This section explains how to configure authorization of DAS subjects over DAS resources.

Roles and Responsibilities

This section describes the Workspace, System, and Stack roles and responsibilities.

Workspace Roles

  • WorkspaceAdministrator has full control of the entire workspace. This includes all workspace-level resources such as users, tokens, and authorization permissions, as well as all systems, stacks and libraries and their sub-resources such as policies and data sources.

  • WorkspaceViewer has read-only permissions over nearly the entire workspace. The WorkspaceViewer is not permitted to read individual system install or uninstall instructions. These instructions can be viewed only by a WorkspaceAdministrator or SystemOwner.

System Roles

  • SystemOwner has full control over any systems they own, including deletion. System owners cannot create new systems.

  • SystemViewer has read-only permissions over nearly all aspects of a system. The SystemViewer is not permitted to read system install or uninstall instructions. These instructions can be viewed by a WorkspaceAdministrator, SystemOwner, or SystemEditor.

  • SystemEditor is able to read and modify most resources belonging to a system, with some restrictions. They cannot modify the system's configuration itself, the internal tokens or the system's authorization permissions.

  • SystemPolicyEditor has full control over a system's policies. They also have read-only permissions over certain system-specific resources such as authorization configuration, validation, log replay, data sources, suggestions, and evaluation.

Stack Roles

  • StackOwner has full control over any stacks they own, including deletion. Stack owners cannot create new stacks.

  • StackViewer has read-only permissions over all aspects of a stack.

  • StackEditor is able to read and modify most resources belonging to a stack, with some restrictions. They cannot modify the stack's configuration or authorization permissions. They are able to read top-level workspace configuration (for example, workspace level Git settings).

  • StackPolicyEditor has full control over a stack's policies. They also have read-only permissions over certain stack resources such as authorization configuration, log replay, data sources, and evaluation.

User Permissions

This section covers adding, editing, and deleting user permissions.

Add Workspace Level

To add user permissions for Alice (an existing user) and Sally (a new user) at the workspace level, do the following:

  1. Click your tenant under WORKSPACE >> Access Control >> Permissions pane.

  2. In the Permissions pane, click the ( ‚®Ā ) plus icon and select Add user permissions‚Ķ button from the drop down list.

  3. In your tenant > Add user permissions dialog, do the following:

    • Users: Select or enter existing users or you can enter new user emails. The existing user alice@hooli.com appears in the drop down list and once selected, her name tag is added in the field and is highlighted in gray color. When the new user sally@hooli.com is entered, her name tag is added in the field and is highlighted in yellow color (indicating Sally is a new user). When Sally logins in through SSO, sally@hooli.com becomes an existing user, appears in the Users drop down list, and Sally's name tag is highlighted.

    • Roles (required): Select or enter a role. For example, enter WorkspaceAdministrator.

  4. Click the Add permissions button.

Now, you have added the user permissions for your tenant.

Edit or delete existing workspace user permissions by clicking on any given row in the Access Control or Permissions page.

Add System or Stack Level

To add user permissions for Alice (an existing user) and Sally (a new user) on the system level or stack level, do the following:

  1. Click on SYSTEMS or STACKS >> Your System or Stack >> Access Control >> Permissions pane.

  2. In the Permissions pane, click the ( ‚®Ā ) plus icon and select Add user permissions‚Ķ button from the drop down list.

  3. In your system > Add user permissions or stack > Add user permissions dialog, do the following:

    • Users: Select or enter existing users or you can enter new user emails. The existing user alice@hooli.com appears in the drop down list and once selected, her name tag is added in the field and is highlighted in gray color. When the new user sally@hooli.com is entered, her name tag is added in the field and is highlighted in yellow color (indicating Sally is a new user). When Sally logins in through SSO, sally@hooli.com becomes an existing user, appears in the Users drop down list, and Sally's name tag is highlighted.

    • Roles (required): Select or enter a role. For example, enter SystemOwner.

  4. Click the Add permissions button.

important

In a future release, Styra will allow permissions on specific packages.

Now, you have added the user permissions for your system or stack.

Edit or delete existing system or stack-level user permissions by clicking on any given row in the Access Control or Permissions page.

API Token Permissions

This section covers adding, editing, and deleting API Token permissions.

Add Workspace Level

To create an API token, see documentation.

note

Creating a token is no longer the complete workflow (regardless of path regular expression). API tokens must also have explicit permissions configured, otherwise they will have no entitlements.

In the previous DAS, when a user creates an API Token, by default, the token is given the same permissions as the user. Since a DAS user must be a WorkspaceAdministrator to create an API Token then all API Tokens are WorkspaceAdministrator with full control of the Workspace. The new DAS Authorization model remedies this by no longer granting an API Token full administrator privileges by default, but by requiring explicit permissions configuration for the token.

In this example, Ruchita is a WorkspaceAdministrator who wants to configure the following token:

  • ruchita_wksp_API_access - Ruchita can use this token with the API to automate creating systems or stacks in the Workspace.

Ruchita adds the token to the Workspace.

In this example, Ruchita wants to use her ruchita_wksp_API_access token to create systems or stacks, so she must make the token a WorkspaceAdministrator on the Workspace level.

Ruchita adds the API token permissions at the Workspace level by doing the following:

  1. In the DAS UI, click WORKSPACE >> hooli >> Access Control >> Permissions.

  2. In the Permissions pane, click the ( ‚®Ā ) plus icon and select Add API token permissions‚Ķ button from the menu to add permissions for your API Token to the Workspace.

  3. In the hooli > Add API token permissions dialog, Ruchita does the following:

    • API tokens (required): Select or enter ruchita_wksp_API_access.

    • Roles (required): Select or enter the role WorkspaceAdministrator.

    • Click the Add API token permissions to Workspace button.

Now, the ruchita_wksp_API_access token WorkspaceAdministrator permissions for workspace-level permissions configuration is added. Ruchita can use the ruchita_wksp_API_access token with the API to create systems or stacks.

Edit or delete existing workspace-level API token permissions by clicking on any given row in the Access Control or Permissions page.

Add System or Stack Level

Ruchita starts to add permissions for the dev3_sys_API_access token system3, so that the DAS users of dev_team3 can use the API on their system.

  1. Click on SYSTEMS or STACKS >> your Custom system or stack >> Access Control >> Permissions** pane.

  2. In the Permissions pane, click the ( ‚®Ā ) plus icon and select Add API token permissions‚Ķ button from the menu.

Ruchita gives the dev3_sys_API_access token SystemOwner permissions for system3.

  1. In your Custom System > Add API token permissions dialog, do the following:

    • API tokens (required): Select or enter dev3_sys_API_access.

    • Roles (required): Select or enter SystemOwner

    • Apply permissions to: Select System from the drop down list.

    • Click the Add API token permissions button.

Now, the dev3_sys_API_access token SystemOwner permissions for system3 is added. The group dev_team3 can use this token with the API to make updates to system3.

Edit or delete existing system or stack-level API token permissions by clicking on any given row in the Access Control or Permissions page.

SSO Claims Permissions

This section covers adding, editing, and deleting SSO claims-based permissions.

Single sign-on (SSO) is a mechanism allowing users to authenticate in your systems and in turn tell DAS that the user has been successfully authenticated. The user is then allowed to access DAS without being required to have a DAS-local user created beforehand and without the user being prompted to enter separate sign-in credentials.

DAS trusts the sign-in requests and only grants access to the users who have been authenticated by your systems. To achieve this, SSO relies on JSON Web Tokens (JWT) for exchanging user authentication data and defining extra claims data, such as known email address, group(s) membership, and so on. This extra data is defined in the payload of the JWT and can be utilized by DAS to automatically map permissions from your Identity Provider to DAS role(s) bound to DAS resources in much the same way as DAS-local users and API tokens.

note

The location of your claims for the purpose of permissions is controlled by the configuration of your SSO Provider in the Scopes field.

Add Workspace Level

In this example, you can do the following for users in SSO provider Hooli Google:

  • Assign any DAS user of the admins group to be a WorkspaceAdministrator for your workspace.

    • The claim reference is the key/value pair: groups=admins. The claim could also be groups=[admins, administrators] to represent list of strings as value, if groups=admins is configured.
  1. Click on workspace >> Access Control >> Permissions pane.

  2. In the Permissions pane, click the ( ‚®Ā ) plus icon and select Add SSO claim permissions‚Ķ button from the drop down list.

  3. In your Add SSO claim permissions dialog, do the following:

    • SSO provider: Select the SSO provider from the drop down list. For example, select Hooli Google.

    • Claim key/value pairs (required): Enter the claim references shown above:

      • groups=admins
    • Roles (required): Select or enter a role.

  4. Click the Add permissions button.

Now, you have added the SSO claim permissions for your tenant.

Edit or delete existing workspace-level SSO claims-based permissions by clicking on any given row in the Access Control or Permissions page.

Add System or Stack Level

In this example, you can do the following for users in SSO provider Hooli Google:

  • Assign any DAS user of the dev_team3 group to be a SystemOwner for your Custom system or stack.

    • The claim reference is the key/value pair: id.groups=dev_team3. The claim could also be groups=[dev_team3,dev_team4] to represent list of strings as value, if groups=dev_team3 is configured.
  • Assign any DAS user of the security department to be a SystemOwner for your Custom system or stack.

    • The claim reference is the key/value pair: department=security.
  1. Click on SYSTEMS or STACKS >> your Custom system or stack >> Access Control >> Permissions pane.

  2. In the Permissions pane, click the ( ‚®Ā ) plus icon and select Add SSO claim permissions‚Ķ button from the drop down list.

  3. In your Custom System > Add SSO claim permissions or Custom Stack > Add SSO claim permissions dialog, do the following:

    • SSO provider: Select the SSO provider from the drop down list. For example, select Hooli Google.

    • Claim key/value pairs (required): Enter the claim references shown above:

      • id.groups=dev_team3

      • department=security

    • Roles (required): Select or enter a role.

  4. Click the Add permissions button.

Now, you have added the SSO claim permissions to a Custom system or stack.

Edit or delete existing system or stack-level SSO claims-based permissions by clicking on any given row in the Access Control or Permissions page.