User Groups

Fine-grained project-based access controls for large and enterprise organizations.

This guide will get you started on how to manage User Groups in Doppler.

πŸ“˜

Groups requires an Enterprise subscription

Want to try it out first? Schedule an enterprise demo.

User Groups provide the fine-grained access controls required by large and enterprise organizations for managing Project ACLs at scale.

User Group allows you to better apply the principle of least privilege by limiting the default workplace user access level for all users and only elevating access per project as required.

Combined with our Enterprise SCIM 2.0 support, users and groups memberships are managed and provisioned from your Identify Provider (IDP). This allows you to define precise grouping based on ActiveDirectory/LDAP membership attributes, or other mapping configurations specific to your IDP such as Application > Role mapping.

Requirements

Management

Groups are managed via the Doppler dashboard with the exception of SCIM (Enterprise required) where they are provisioned based on mappings from your IDP.

Below is a table showing how Users and Groups are managed based on your SSO method.

SSO

Manage Users

Manage Groups

Email SSO

Dashboard

Dashboard

SAML

IDP

Dashboard

SCIM 2.0

IDP

IDP

Dashboard Created Groups

Email SSO and SAML require Groups to be created manually via the Doppler dashboard.

For team/project-based groups (eg. Frontend), we recommend setting the Project Access level to Collaborator whereas role-based groups that work cross-functionally (e.g. DevOps) are a better fit for Admin level access.

Project Access

Granting Project access to Groups is the same as users. Click on the Members button from the Project overview page, then select which Group(s) to add to the Project.

SCIM

SCIM is the ideal method for managing Doppler Groups as it automates the provisioning and membership mapping based on assignment rules configured in your IDP.

Once the Groups are provisioned in Doppler, workplace owners and admins can then edit the project access levels for each group.

Group Mapping and Provisioning

Every organization has its unique way of managing users and groups (e.g. AD, LDAP, or built-in IDP user management) so we're not able to offer a single guide that caters to every setup.

Consult the SCIM Groups mapping documentation for your IDP to learn which strategy will work best, e.g. Group membership based on regex matching of AD/LDAP field values or using the built-in Roles functionality of your IDP.

Or alternatively, reach out via in-product support and we can help guide you towards the best solution.

πŸ“˜

The SCIM Access Level defines both the default Workplace and Group membership access levels. We recommend keeping this at Collaborator.

Implementation Advice

While each organization’s approach to Group management will likely differ, here is some general implementation advice to keep in mind.

Configure Workplace Logging Services

We recommend configuring Workplace Activity Logs in order to capture any User and Group-related events that occur in Doppler. This is especially important for tracking Doppler-specific user management activities that won't be captured by your IDP (e.g. Groups management when using SAML).

Collaborator for Default Access Level

We recommend keeping the default access level as Collaborator so access to environments is given on a group-by-group basis.

Projects Access for Groups and Individual Users

While it’s best to utilize Groups as much as possible for bulk Project access management, adding individual users to a Project is an option to keep in mind when the Group mapping from your IDP is not flexible enough, or if a user needs temporary access to a Project.

If using SCIM however, we recommend adding a user-specific mapping within your IDP in order to keep your IDP the source of truth which also ensures your IDP audit log captures every access level change.

Limit workplace admins by using a Group with Admin Access

As a Workplace level Admin has edit access to every project, we recommend using Groups with Admin permissions that can be selectively applied to projects as needed.

FAQs

How should I structure groups/roles? By job role group, team/department, project groupings?

Generally, a mix of teams (e.g. frontend) and role-based groups (e.g. QA, DevOps) is recommended.

For example:

Group

Access

Frontend

Collaborator (development, staging)

QA

Viewer (staging)

DevOps

Admin

Is it possible to have groups on the Pro plan?

We recognize that early-stage companies undergoing rapid growth may need some, but not all enterprise features. We can't promise anything, but reach out to us with what you need and we'll see what we can do.


Did this page help you?