Skip to content

SAML Group Sync

Problem to solve

Current behavior with SAML SSO for Groups: Users authenticate into a Parent Group with a default role. 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 third party software 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 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. It would be ideal if we can extend to all the currrently supported SAML SSO providers.

Intended users

User experience goal

  • Allow teams using SAML to automatically manage user roles within the subgroups of a top-level group on behalf of their users.
  • Give users the ability to update subgroup permissions for their user by logging in with SAML.

This will:

  • 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

Iteration Plan:

After these issues are complete this issue will be closed 😄

End State:

n_current
d1
d2
d3
d4

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.

Is this a cross-stage feature?

No

Links / references

Dev: https://dev.gitlab.org/gitlab/gitlab-ee/issues/334

Zendesk tickets

Requested feature

Patricio

3 big companies are asking if our SAML implementation supports the transfer of group memberships to GitLab, just like our LDAP Group Sync does. Unfortunately it is not possible, as SAML only serves as an Omniauth provider and nothing else.

Concrete questions / Next steps

Implementing this will require GitLab to directly use the ruby-saml gem for group management in a similar way we do right now for LDAP.

dzaporozhets what do you think about adding such a feature to EE?

Dmitriy

makes sense. I think we should not promise it anyone before investigating if its possible.

I might be wrong but I think you added SAML support to GitLab. Can you check if group sync with SAML is something that can be done without going to hell? I think its not urgent so 8.1 or 8.2 for investigation should be fine. cc sytse

Marin

I didn't build SAML support, CERN did. If there is someone else available to investigate this please take over as I have lots of things to handle in omnibus-gitlab.

Customers

Issue readiness

  • Product: issue description is accurate with an acceptable proposal for an MVC
  • Engineering: issue is implementable with few remaining questions, is sufficiently broken down, and is able to be estimated
Edited by Bryan Miller