### Problem to solve Enterprise customers on Gitlab.com want to be able to fully manage the entire lifecycle of users in their groups. This desire is both for efficiency and to protect their intellectual property. Typically, these customers will have centralized user management for their enterprise through an IdP like Okta or Azure and use GitLab SSO/SCIM. There are three ways that users can join a SAML enabled group today: 1. Users are provisioned using SCIM and join the group when they follow a GitLab SAML URL 2. Users create an account after following a GitLab SAML URL. The user links this new account to their SAML identity. 3. Users already have a GitLab account and link it to their SAML identity when they follow a GitLab SAML URL Our terms and conditions did not indicate that group administrators had any ownership of those accounts. Accounts that are provisioned for a group (scenarios 1 and 2 above) can be used to participate in any group/project in GitLab.com. Over time, users can collect intellectual property that doesn't belong to the organization they were provisioned for. Accounts that existed and were invited into a group (scenario 3) may have participated in other groups and contain intellectual property from another organization. This dynamic prevented us from allowing administrators from fully managing users that are part of their group. We now have the following legal definition, which allows Enterprise customers official control over their Enterprise Users: ### Legal Definition of Enterprise User As of 2021-02-01 when our terms were last updated, we introduced the definition of an enterprise user. Enterprise user accounts belong to the company that purchased a GitLab subscription. This means when requested by an Owner in the top-level of a paid group, information can be shared about, and actions can be made on behalf of an enterprise user. In situations where proof of account ownership is required, then either the relevant user or requesting owner can pass the verification process. A user is considered an enterprise user when: * The user's email has a domain that is owned by the company of the paid group, and The user account meets one of the following conditions: * was created 2021-02-01 or later * has a SAML or SCIM identity tied to the organization's group. * has a provisioned_by_group_id value that is the same as the organization's group's ID. * is a member of the organization's group, where the subscription was purchased or renewed 2021-02-01 or later. Taken from [here](https://about.gitlab.com/handbook/support/workflows/gitlab-com_overview.html#enterprise-users) ### Intended users * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### Proposal Our [Subscription Agreement](https://about.gitlab.com/handbook/legal/subscription-agreement/) was updated in early 2021. We can build functionality to support to cover the use cases below: | User Type | Solution | |-----------|----------| | `Individual Signing on Behalf of Individual But Using Company Email. IF THE INDIVIDUAL ACCEPTING THIS AGREEMENT IS ACCEPTING THIS AGREEMENT ON HIS OR HER OWN BEHALF BUT USING AN ENTERPRISE EMAIL ADDRESS TO DO SO, SUCH INDIVIDUAL ACKNOWLEDGES AND AGREES THAT USE OF SUCH ENTERPRISE EMAIL ADDRESS WILL ESTABLISH A GITLAB ACCOUNT THAT WILL BE ASSOCIATED WITH THE APPLICABLE ENTERPRISE, AND CAN AND WILL BE TRANSFERRED ENTIRELY (BOTH CONTROL AND DATA/INFORMATION WITHIN THE ACCOUNT) TO SUCH ENTERPRISE UPON SUCH COMPANY’S REQUEST WITHOUT NOTICE OR LIABILITY TO THE INDIVIDUAL. AS SUCH, TO ENSURE NO LOSS OF PERSONAL CONTENT, GITLAB STRONGLY RECOMMENDS ESTABLISHING A GITLAB ACCOUNT TIED TO A PERSONAL EMAIL ADDRESS.` | Provide group maintainers+ administrative control over users whose email matches a domain that they have proved ownership over. Provide group maintainers+ administrative control over users that were provisioned in the context of their group. | For simplicity, those users will be referred to as _Enterprise Users_. We will provide additional management capabilities for Enterprise Users that increase the degree of isolation in GitLab.com groups. For example: * To prevent accidental disclosure of intellectual property, group maintainer+ can change attributes on their users so they cannot create groups or projects outside of their enterprise group's top-level namespace. * Group maintainer+ can choose if their users can keep an account after they leave their group. * Administrators can claim one or more domains and will own users that are created with those domains. * Users that provision accounts for use with a group will have very clear messaging that this account is only for use with that group. Their welcome email will clearly state this. * Users that create an account with an email that matches a domain that has been claimed will have very clear messaging that this account will be owned by a group. Their welcome email will clearly state this. * Group owners get increased tooling around serving their users, including impersonation and ability to reset their user's 2FA. This approach is different from Group Managed Accounts because it does not depend on group membership. Existing accounts will not automatically become managed if they join a group. Group administrators will have more flexibility over the level of control they wish to assert on those accounts. ### Further details Iteration Path: * [Allow users to be created with SAML and tie to a group in the backend](https://gitlab.com/gitlab-org/gitlab/-/issues/268142 "SAML user provisioning") - Completed 13.7 * [Tie SCIM created accounts to a group in the backend](https://gitlab.com/gitlab-org/gitlab/-/issues/283935 "Mark SCIM Account Group Origin") - Completed 13.7 * [Send custom email to accounts created via SAML or SCIM](https://gitlab.com/gitlab-org/gitlab/-/issues/276018 "Enterprise Users - Welcome Email") - Completed 13.8 * [Allow setting project_limit and can_create_project with SAML user creation](https://gitlab.com/gitlab-org/gitlab/-/issues/263661 'Provisioned Accounts - Allow setting "Project limit" and "Can create groups" attributes') - Completed 13.7 * [Disable password auth](https://gitlab.com/gitlab-org/gitlab/-/issues/300191 "Enterprise users - Disallow Password Auth") - Targeted for 13.12 behind a feature flag * [Update project_limit and can_create_project on all SAML responses](https://gitlab.com/gitlab-org/gitlab/-/issues/321940 "Update project_limit and can_create_groups for Enterprise Users on all SSO responses") Completed 14.5 * [Domain Verification MVC using GitLab Pages](https://gitlab.com/gitlab-org/gitlab/-/issues/353030) Completed 15.4 * [Email verification bypass -](https://gitlab.com/gitlab-org/gitlab/-/issues/238461) Completed 15.4 * [Automatically claim any user matching a verified domain](https://gitlab.com/gitlab-org/gitlab/-/issues/322039) - 15.7 * [Group owner can reset 2FA](https://gitlab.com/gitlab-org/gitlab/-/issues/372401) 15.7 * [Group owner can pull e-mail addresses via API ](https://gitlab.com/gitlab-org/gitlab/-/issues/26068)- 15.7 * [Simplify Domain Verification](https://gitlab.com/gitlab-org/gitlab/-/issues/375492) - %"16.0" * [Automated Claims for Users Matching a Verified Domain](https://gitlab.com/groups/gitlab-org/-/epics/9675) - %"16.0" * [Prevent E-mail address changes](https://gitlab.com/gitlab-org/gitlab/-/issues/15159) - %16/0 * [Lift flag to disable password auth](https://gitlab.com/gitlab-org/gitlab/-/issues/373718)- Tentative %"16.1" * * [Add "Managed By" Badge to Enterprise User Accounts](https://gitlab.com/gitlab-org/gitlab/-/issues/372895) - %"16.1" * [Retain IP after account deactivation / Prevent User from Deleting Account](https://gitlab.com/gitlab-org/gitlab/-/issues/7237) - %"16.2" * [User invites must match verified domain](https://gitlab.com/gitlab-org/gitlab/-/issues/348834) * Impersonate Enterprise Users * Define Session Policies for Enterprise Users * Credential Management * Enforce Credential Rotation Policy for Enterprise Users