Allow selective SSO enforcement for Gitlab.com subgroups
Problem to solve
When SSO is being enforced while using Group SSO, we enforce SSO for the entire group hierarchy. Some organizations would like to selectively allow contractors/customers access to certain projects and groups without needing to onboard them into their IdP. These users are typically outside of a connected identity provider, and won't be able to SSO in.
Target audience
Sidney, Systems Administrator may be relevant, but this is mostly a feature of interest for any group Owner on GitLab.com who is enforcing SSO for their organization.
Proposal
We should allow group admins to determine if SSO should be enforced on the whole hierarchy or if subgroup owners can turn off the enforcement requirement.
The Owner of the top-level group can decide whether or not subgroups have SSO enforced.
- If SSO enforcement is enabled in a top-level group, then SSO enforcement cannot be turned off in a subgroup.
- If SSO enforcement is not enabled in a top-level group, then SSO enforcement can be turned on/off in a subgroup.
What does success look like, and how can we measure that?
- An SSO configured group can have a subgroup where SSO is not enforced and a subgroup where SSO is enforced.