Map & Sync SAML SSO groups directly to GitLab Groups and Subgroups
Problem to solve
Current behavior with SAML SSO for Groups: Users authenticate into a Parent Group with Guest permissions. They are then assigned membership/rights into other Subgroups by other users (or scripting). SSO is used for authentication only, membership in GitLab has no association with SSO Groups.
Use Case to Solve: Enterprise security policy requires all 3P software RBAC/permissions to be authorized through SSO groups. Controlling/assigning membership & permissions to GitLab Groups/Subgroups, outside of SSO group associations, is not permissible.
This proposed SSO Group syncing feature will allow GitLab to support enterprises such that they can configure, and enforce "SSO Group A has access to GitLab Subgroup Z, with Developer Permissions"
This is related to &1986 but outlines additional needs.
This proposal assumes the customer/buyer has defined sufficiently granular SSO groups, which would allow for 1-1 mappings. I.e. the set people assigned to a single SSO group all have the same work role, and thus would assume the same GitLab Permissions within a GitLab group.
It would be possible to map multiple SSO Groups to a single GitLab Group/Subgroup. This will be necessary to meet the regular requirement that to have different permissions levels within a Group (i.e some people are Developers, others Maintainers). It also allows for multiple teams of users have access to the same Group. (see diagrams below)
This feature request and customer use case applies to GitLab.com and self-managed instances equally. My customer, and my examples, will be for GitLab.com.
My customer needs Okta to be supported in the manner described below, but it would be ideal if we can extend to all the currrently supported SAML SSO providers.
Intended users
User experience goal
- Remove the overhead to team leads/devOps (or whomever else would be responsible) of having to assign/map users to GitLab Groups/Subgroups, when sufficient SSO groups have already been defined to organization users based on role/responsibility
- Allow GitLab to be adopted by organizations whose security policy requires centralized enforcement of RBAC, via their SSO group definitions, for all 3P tools.
Proposal
Permissions and Security
I would expect this to be an administrative option on the group for Maintainer and above.
-
Add expected impact to members with no access (0) -
Add expected impact to Guest (10) members -
Add expected impact to Reporter (20) members -
Add expected impact to Developer (30) members -
Add expected impact to Maintainer (40) members -
Add expected impact to Owner (50) members -->
Documentation
Not known at this time.
Availability & Testing
For the first iteration of this feature, I need Okta supported.
What does success look like, and how can we measure that?
Success will be allowing membership and permissions in GitLab Groups to be authorized & enforced by the configuration of SSO groups.
What is the type of buyer?
This impacts every large enterprise buyer where they also need to adhere to internal SSO and RBAC security policies.
This mapping feature would be included in the Silver tier with other SSO support features.
Is this a cross-stage feature?
For technical implementation, I do not believe so.