Authentication (sometimes called
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 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.
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:
Ruchitashould have full control of the Workspace level.
dev_team3should have full control of the System level.
Aliceshould 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:
Write a custom role called
Aliceto that role on Workspace level. You can also write a custom Rego rule that allows
Aliceto 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
WorkspaceAdministratorfor Workspace level, then the user will view and administer the Workspace.