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.
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|
Dashboard Created Groups
Email SSO and SAML require Groups to be created manually via the Doppler dashboard.
For team/project-based groups (e.g. 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.
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.
Default Project Role
A default project role can optionally be assigned to a group. Whenever the group is added to a project, the group will automatically get this role. You can override it per-project or leave it as the workplace's default role.
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.
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.
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.
|Frontend||Collaborator (development, staging)|
Is it possible to have groups on the Team 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.
Updated 2 months ago