Transparent SSO enforcement for group members on GitLab.com
Problem to solve
Allow enforced SSO for group members but still allow non-members to access without SSO, for public/internal projects. This would be useful for GitLab's own use of SSO in gitlab-org and gitlab-com. This idea came about from dogfooding discussions with @lmcandrew for https://gitlab.com/gitlab-org/manage/-/issues/16431.
Currently, the SSO Enforcement requires all users to use SSO to access a group and its projects. This precludes GitLab from using the feature with the gitlab-org and gitlab-com groups because we have open-source projects.
Proposal
I believe we can accomplish this by checking whether a user has a matching SAML identity upon accessing the group or its projects. If there's a matching identity, make sure the user has an active SSO session or send them to the IdP to authenticate. We wouldn't want to do this check on every request so there should probably be some cache, too. The flow might look like:
- User accesses a group or project where SSO is enabled.
- GitLab checks if the user is an actual member (as opposed to outside user accessing a public or internal project).
- If a matching identity, send through the SSO process.
- As an adaptation here we could skip checking for a matching identity and send all members through the SSO process.
- If a member, check if the user has a matching SAML identity.
- User is able to access the group and its projects as normal.
What does success look like, and how can we measure that?
GitLab is able to enable SSO on gitlab-org and gitlab-com and all group and project members will be required to use SSO, while the public will not have to use SSO and can continue accessing GitLab projects as normal.