Domain Verification MVC using Domain(s) verified via GitLab Pages
Goal
Enterprise customers want complete control over their users. "Their users" are defined as anyone with an "@enterprise.com" email address.
As an enterprise administrator, I want to be able to claim existing GitLab users that belong to my domain(s) and have control over them. I want to legally own all of the IP that exists under this account.
In order to achieve this, we need to have a manual process where a human can verify that the domain verification is legit. If it is, the provisioned_by_group_id
can be set, making the user an Enterprise User.
Background
Existing solution for this is in the provisioned_by_group_id
flag. This gets set when users are provisioned via SCIM.
MVC Definition
✏ ️ Figma work file
🧙♀️ Wizard text
Get started with GitLab Pages
GitLab Pages lets you deploy a static website in minutes. You can:
- Follow the steps below to create pipeline configuration using a wizard.
- Skip these steps to configure GitLab Pages manually, including domain verification.
⚙ ️ Group Settings Proposal:
Note: This needs to work on GitLab.com and should be behind a feature flag that is disabled by default.
- Domain verification already exists in GitLab Pages. Let's take advantage of these domains that are already verified.
- Any domain that is verified via Pages is considered verified for the purpose of turning users into Enterprise users.
- This feature lives behind a feature flag
- Group owner navigates to Group Settings and sees a list of all domains verified with Pages
- Presence of a button with "Claim Users"
- A warning message appears when user clicks "Claim Users".
- This will claim any users that have a primary email address matching the domains X, Y, and Z (exact text TBD). This change is not reversible, are you sure you want to proceed?
- User clicks yes, window disappears and progress bar is displayed "XX of YY users claimed" status until the process is complete
- List of users claimed (username, email address). This list is historically visable.
- User clicks no, exit out of process
- This button updates
provisioned_by_group_id
to match the group ID of the verified domain - Open Question: Should we create another field behind the scenes to mark this as a "claimed user" via this process? Would be helpful to know who was provisioned vs who was claimed.
Legal Question:
- Q: Can we automatically take an account and, as long as it has an
___@enterprise-name.com
email address, have it be claimed by the organization without notifying the user? The thought was that due to the MVC, the organization would notify its users of the claim process if they wanted to.
A: This is technically included in our EULA and would be allowed, but we need to consider customer experience.
User Experience
- There is concern that having your account suddenly claimed by your company with no warning is not a good user experience. Do we need to provide some kind of notification to users before they are claimed?
- I have done some customer discovery around this and they are not empathetic to these concerns, they believe that their users should realize if they are using their work e-mail as a primary account e-mail address, it is owned by the company
Tier
GitLab Premium GitLab Ultimate
Feature flag?
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.