"User access" is not "Model access"

This page covers user groups and access, including:

• User licenses, permissions, and group memberships
• Role-based access controls for projects and environments
• Single sign-on, and secure authentication

For model-specific access and their availability across projects, refer to Model access.

About user access

You can regulate access to dbt by various measures, including licenses, groups, permissions, and role-based access control (RBAC). To understand the possible approaches to user access to dbt features and functionality, you should first know how we approach users and groups.

Users

Individual users in dbt can be people you manually invite or grant access via an external identity provider (IdP), such as Microsoft Entra ID, Okta, or Google Workspace.

In either scenario, when you add a user to dbt, they are assigned a license. You assign licenses at the individual user or group levels. When you manually invite a user, you will assign the license in the invitation window.

Example of the license dropdown in the user invitation window.

You can edit an existing user's license by navigating to the Users section of the Account settings, clicking on a user, and clicking Edit on the user pane. Delete users from this same window to free up licenses for new users.

Example of the user information window in the user directory

User passwords

By default, new users will be prompted to set a password for their account. All plan tiers support and enforce multi-factor authentication for users with password logins. However, they will still need to configure their password before configuring MFA. Enterprise tier accounts can configure SSO and advanced authentication measures. Developer and Starter plans only support user passwords with MFA.

User passwords must meet the following criteria:

• Be at least nine characters in length
• Contain at least one uppercase and one lowercase letter
• Contain at least one number 0-9
• Contain at least one special character

Groups

Groups in dbt serve much of the same purpose as they do in traditional directory tools — to gather individual users together to make bulk assignments of permissions easier.

The permissions available depends on whether you're on an Enterprise-tier or self-service Starter plan.

• Admins use groups in dbt to assign licenses and permissions.
• The permissions are more granular than licenses, and you only assign them at the group level; you can’t assign permissions at the user level.
• Every user in dbt must be assigned to at least one group.

There are three default groups available as soon as you create your dbt account (the person who created the account is added to all three automatically):

• Owner: This group is for individuals responsible for the entire account and will give them elevated account admin privileges. You cannot change the permissions.
• Member: This group is for the general members of your organization. Default permissions are broad, restricting only access to features that can alter billing or security. By default, dbt adds new users to this group.
• Everyone: A general group for all members of your organization. Customize the permissions to fit your organizational needs. By default, dbt adds new users to this group.

Default groups are automatically provisioned for all accounts to simplify the initial set up. We recommend creating your own organizational groups so you can customize the permissions. Once you create your own groups, you can delete the default groups.

Create new groups EnterpriseEnterprise +

• Create new groups from the Groups & Licenses section of the Account settings.
• If you use an external IdP for SSO, you can sync those SSO groups to dbt from the Group details pane when creating or editing existing groups.

Example the new group pane in the account settings.

important

If a user is assigned licenses and permissions from multiple groups, the group that grants the most access will take precedence. You must assign a permission set to any groups created beyond the three defaults, or users assigned will not have access to features beyond their user profile.

SSO mappings EnterpriseEnterprise +

SSO Mappings connect an identity provider (IdP) group membership to a dbt group. When users log into dbt via a supported identity provider, their IdP group memberships sync with dbt. Upon logging in successfully, the user's group memberships (and permissions) will automatically adjust within dbt.

Creating SSO Mappings

While dbt supports mapping multiple IdP groups to a single dbt group, we recommend using a 1:1 mapping to make administration as simple as possible. Use the same names for your dbt groups and your IdP groups.

Create an SSO mapping in the group view:

1. Open an existing group to edit or create a new group.
2. In the SSO portion of the group screen, enter the name of the SSO group exactly as it appears in the IdP. If the name is not the same, the users will not be properly placed into the group.
3. In the Users section, ensure the Add all users by default option is disabled.
4. Save the group configuration. New SSO users will be added to the group upon login, and existing users will be added to the group upon their next login.

Example of an SSO group mapped to a dbt group.

Refer to role-based access control for more information about mapping SSO groups for user assignment to dbt groups.

Grant access

dbt users have both a license (assigned to an individual user or by group membership) and permissions (by group membership only) that determine what actions they can take. Licenses are account-wide, and permissions provide more granular access or restrictions to specific features.

Licenses

Every user in dbt will have a license assigned. Licenses consume "seats" which impact how your account is billed, depending on your service plan.

There are four license types in dbt:

• Analyst — Available on Enterprise and Enterprise+ plans only. Requires developer seat license purchase.
  • User can be granted any permission sets.
• Developer — User can be granted any permission sets.
• IT — Available on Starter, Enterprise, and Enterprise+ plans only. User has Security Admin and Billing Admin permissions applied.
  • Can manage users, groups, and licenses, among other permissions.
  • IT licensed users do not inherit rights from any permission sets.
  • Every IT licensed user has the same access across the account, regardless of the group permissions assigned.
• Read-Only — Available on Starter, Enterprise, and Enterprise+ plans only.
  • User has read-only permissions applied to all dbt resources.
  • Intended to view the artifacts and the deploy section (jobs, runs, schedules) in a dbt account, but can’t make changes.
  • Read-only licensed users do not inherit rights from any permission sets.
  • Every read-only licensed user has the same access across the account, regardless of the group permissions assigned.

Developer licenses will make up a majority of the users in your environment and have the highest impact on billing, so it's important to monitor how many you have at any given time.

For more information on these license types, see Seats & Users

Permissions

Permissions determine what a developer-licensed user can do in your dbt account. By default, members of the Owner and Member groups have full access to all areas and features. When you want to restrict access to features, assign users to groups with stricter permission sets. Keep in mind that if a user belongs to multiple groups, the most permissive group will take precedence.

The permissions available depends on whether you're on an Enterprise, Enterprise+, or self-service Starter plan. Developer accounts only have a single user, so permissions aren't applicable.

Example permissions dropdown while editing an existing group.

Some permissions (those that don't grant full access, like admins) allow groups to be "assigned" to specific projects and environments only. Read about environment-level permissions for more information on restricting environment access.

Example environment access control for a group with Git admin assigned.

Role-based access control EnterpriseEnterprise +

Role-based access control (RBAC) allows you to grant users access to features and functionality based on their group membership. With this method, you can grant users varying access levels to different projects and environments. You can take access and security to the next level by integrating dbt with a third-party identity provider (IdP) to grant users access when they authenticate with your SSO or OAuth service.

There are a few things you need to know before you configure RBAC for SSO users:

• New SSO users join any groups with the Add all new users by default option enabled. By default, the Everyone and Member groups have this option enabled. Disable this option across all groups for the best RBAC experience.
• You must have the appropriate SSO groups configured in the group details SSO section. If the SSO group name does not match exactly, users will not be placed in the group correctly.
  The Group details SSO section with a group configured.
• dbt Labs recommends that your dbt group names match the IdP group names.

Let's say you have a new employee being onboarded into your organization using Okta as the IdP and dbt groups with SSO mappings. In this scenario, users are working on The Big Project and a new analyst named Euclid Ean is joining the group.

Check out the following example configurations for an idea of how you can implement RBAC for your organization (these examples assume you have already configured SSO):

 Okta configuration

You and your IdP team add Euclid Ean to your Okta environment and assign them to the dbt SSO app via a group called The Big Project.

The user in the group in Okta.

Configure the group attribute statements the dbt application in Okta. The group statements in the following example are set to the group name exactly (The Big Project), but yours will likely be a much broader configuration. Companies often use the same prefix across all dbt groups in their IdP. For example DBT_GROUP_

Group attributes set in the dbt SAML 2.0 app in Okta.

 dbt configuration

You and your dbt admin team configure the groups in your account's settings:

1. Navigate to the Account settings and click Groups & Licenses on the left-side menu.
2. Click Create group or select an existing group and click Edit.
3. Enter the group name in the SSO field.
4. Configure the Access and permissions fields to your needs. Select a permission set, the project they can access, and environment-level access.

The group configuration with SSO field filled out in dbt.

Euclid is limited to the Analyst role, the Jaffle Shop project, and the Development, Staging, and General environments of that project. Euclid has no access to the Production environment in their role.

 The user journey

Euclid takes the following steps to log in:

1. Access the SSO URL or the dbt app in their Okta account. The URL can be found on the Single sign-on configuration page in the Account settings.

The SSO login URL in the account settings.

2. Login with their Okta credentials.

The SSO login screen when using Okta as the identity provider.

3. Since it's their first time logging in with SSO, Euclid Ean is presented with a message and no option to move forward until they check the email address associated with their Okta account.

The screen users see after their first SSO login.

4. They now open their email and click the link to join dbt Labs, which completes the process.

The email the user receives on first SSO login.

Euclid is now logged in to their account. They only have access to the Jaffle Shop pr, and the project selection option is removed from their UI entirely.

The home screen with access restricted.

They can now configure development credentials. The Production environment is visible, but it is read-only, and they have full access in the Staging environment.

The Production environment landing page with read-only access.

The Staging environment landing page with full access.

With RBAC configured, you now have granular control over user access to features across dbt.

SCIM license management

As part of the SSO configuration for supported IdPs, you can also configure the System for Cross-Domain Identity Management (SCIM) settings to add a layer of security to your user lifecycle management. As part of this process, you can integrate user license distribution into the user provisioning process through your IdP. See the SCIM license management instructions for more information.

FAQs

 When are IdP group memberships updated for SSO Mapped groups?

Group memberships are updated whenever a user logs into dbt via a supported SSO provider. If you've changed group memberships in your identity provider or dbt, ask your users to log back into dbt to synchronize these group memberships.

 Can I set up SSO without RBAC?

Yes, see the documentation on Manual Assignment above for more information on using SSO without RBAC.

 Can I configure a user's license type based on IdP attributes?

Yes, see the docs on managing license types for more information.

 Why can't I edit a user's group membership?

Don't try to edit your own user, as this isn't allowed for security reasons. You'll need a different user to make changes to your own user's group membership.

 How do I add or remove users?

Each dbt plan has a base number of Developer and Read-Only licenses. You can add or remove licenses by modifying the number of users in your account settings.

• If you're on an Enterprise or Enterprise+ plan and have the correct permissions, you can add or remove developers by adjusting your developer user seat count in Account settings -> Users.
• If you're on a Starter plan and have the correct permissions, you can add or remove developers by making two changes: adjust your developer user seat count AND your developer billing seat count in Account settings -> Users and then in Account settings -> Billing.

For detailed steps, refer to Users and licenses.