Skip to main content

Overview

Authentication (sometimes called Identity or log-in) and Authorization (controlling which identities can perform which actions) are handled through industry-standard mechanisms username/passwords, SSO, API tokens, and Role-Based Access Control (RBAC)/Attribute-Based Access Control (ABAC)/Rego policies.

Authentication

Authentication to the Styra DAS is handled in one of the following ways:

  • Username and password: You can invite new users by providing their email address, and they go through a standard email sign-up flow. This ensures that the user actually owns that email address and allows them to reset their password through email.

  • Single Sign-On (SSO): Instead of managing users and passwords within the DAS you can manage users in an identity-provider. An administrator needs to configure the SSO provider and then dictate who has access to the DAS in that identity-provider.

  • API tokens: You may create tokens that can be embedded within API calls to the Styra DAS. These API tokens are used by OPA to communicate with the DAS; they are also used frequently by automation to create new systems and policies on demand. These tokens expire, have owners, and other metadata.

Also, you can use all the above authentication options together. Some users can authenticate through usernames and passwords, which most often happens when they are using the GUI, but they can also use the CLI. Other users can authenticate using a SSO provider to use the GUI, and software systems authenticate using an API token.

Authorization

Authentication allows you to grant users and machines access to the Styra DAS; whereas Authorization allows you to control which actions those users and machines can perform on the DAS.

The DAS aims to make the common case easy and the uncommon case possible. The common case is handled by assigning users/groups/tokens to one or more roles. A role is a pre-built collection of permissions. For more granularity you can assign users to roles on a specific resource (for example, a single DAS System). For the uncommon case, you can write Rego policies to define custom roles or even custom rules that make whatever authorization decision you want.

For example, you can write a policy for the following users:

  • Ruchita should have full control of the Workspace level.

  • dev_team3 should have full control of the System level.

  • Alice should be given read-only control for the Workspace level to see the list of violations that require a fix.

To implement that policy with the Styra DAS, you must assign the following roles:

  • Assign Ruchita to the WorkspaceAdministrator role.

  • Assign dev_team3 to the SystemOwner role.

  • Write a custom role called WorkspaceViewer and assign Alice to that role on Workspace level. You can also write a custom Rego rule that allows Alice to access APIs when running in the Workspace level.

When you assign roles, you can assign them to each of the different forms of authentication that the DAS supports.

  • User IDs: These are often in the form of email addresses.

  • SSO claims: When a user authenticates via SSO, there are SSO claims that can be assigned roles.

  • API tokens: Each API token can be assigned roles.

When it comes to assigning roles, a user is granted the union of the permissions of all the roles the user is assigned. For example, if a user is granted both WorkspaceViewer and WorkspaceAdministratorfor Workspace level, then the user will view and administer the Workspace.

note
  1. The Styra DAS GUI is used to assign roles and responsibilities to the users.

  2. To learn about the Authorization operations for all system types, see the Authorization page.