<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> Our Commercial customers have expressed interest in a way to add users to their groups without validating their emails. The theory is, if they come through their SSO solution, they should not need to be verified again in GitLab. Since this could result in a security issue, the verifying of emails coming through SSO should be limited to domains the customer proves ownership over. Related to https://gitlab.com/gitlab-org/gitlab/-/issues/23611. If an email added through SSO does not belong to the customer's group verified domain(s), then it should require extra validation. We should not automatically validate emails for any other domains coming through SSO. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [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) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) --> * [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) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> Users coming to GitLab from corporate SSO should have a seamless adoption experience if the customer has already verified ownership of their corporate domains. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Allow customers to add verified domains to their GitLab.com hosted group as described in https://gitlab.com/gitlab-org/gitlab/-/issues/23611. The framework for such a feature already exists within [Pages Custom domains and SSL/TLS Certificates](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/). We can then use that verified domain to auto-verify account emails that belong to that verified domain. We could expand this a little more and prevent users from adding additional emails to these types of accounts. Tying into and further locking down [Group Managed Accounts](https://docs.gitlab.com/ee/user/group/saml_sso/group_managed_accounts.html). ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> When users are added through SSO that do not have resolvable emails, they are unable to validate them. Since SaaS users do to have access to admin tools, users need to open a support ticket to resolve. We have customers that run into this issue on a regular basis, requiring many tickets to validate those accounts. We should make it easier for companies and their employees to adopt and grow their userbase, with as little friction to getting started as possible, while also keeping their groups secure. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html * [ ] 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 --> Only group Owners should be able to verify a corporate domain and enable the verification bypass on that verified domain. Both in the UI and via the API. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> - [Group Managed Accounts](https://docs.gitlab.com/ee/user/group/saml_sso/group_managed_accounts.html) - amended to add the auto-verify option. Describing that feature is available after a domain is verified. - [GitLab authentication and authorization](https://docs.gitlab.com/ee/administration/auth/) - all providers updated to note how to enable the bypass of validation for verified emails. - [Group Advanced Settings](https://docs.gitlab.com/ee/user/group/#advanced-settings) - describes how to verify the domain in their group. Self-managed customers can already bypass the validation by disabling [User email confirmation at sign-up](https://docs.gitlab.com/ee/security/user_email_confirmation.html). They also have admin rights, so can do all of the things described in [Updating to GitLab 13.2: Email confirmation issues](https://docs.gitlab.com/ee/user/upgrade_email_bypass.html#what-do-i-need-to-know-as-an-administrator-of-a-gitlab-self-managed-instance) ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> Success is customer SSO accounts being created with their corporate domains without any friction. Measured by the reduction in support tickets and requests to verify corporate domain accounts. ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> * [Skyler (Chief Information Security Officer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/#skyler---the-chief-information-security-officer) For the SSO validation bypass, the tier could be Ultimate/Gold based on the type of buyer. It would fit better in Premium/Silver with the rest of the Group SSO features. This feature was initially requested by a current Ultimate customer - https://gitlab.my.salesforce.com/0016100000KvahJ (Internal) and entered on their behalf. ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> Based on the proposal, suspect the following groups/stages: - ~"devops::manage" ~"group::access" ~"group::compliance" - ~"devops::create" ~"group::static site editor" ~"group::ecosystem" ### Links / references Directly related to [Group domain verification](https://gitlab.com/gitlab-org/gitlab/-/issues/23611) <!-- Label reminders - you should have one of each of the following labels if you can figure out the correct ones --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->