Modular Group Authentication

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem to solve

Today, self-managed GitLab instances have the choice of either unilateral authentication configuration (i.e. an instance-wide SAML configuration where all auth flows tie back to a central identity provider (I'd estimate 95+% of all instances with SAML opt for this), or, implementing Group SAML, which is what's used to operate GitLab.com as a shared multi-tenant instance.

With Group SAML, every single top-level namespace can optionally be configured with an independent auth flow, but if not, only native GitLab accounts can be used.

Proposal

As a security minded large enterprise with a broadly-used identity solution, but some exceptional situations, neither solution described above is ideal.

We should allow an instance to be configured with a default SAML provider, and permit select groups to be configured with an alternate provider.

An MVC might be simple, where groups that have distinct SAML configuration are excluded from the instance default. The path-based IdP/auth routing and identity pieces that are used for Group SAML would provide a lot of the required UX pieces already:

e.g. if I navigate to gitlab.corp.com/normal-group, I'll be presented with the auth flow configured as the instance default, but if I navigate to gitlab.corp.com/super-secure, I'm presented with a prompt to authenticate via another IdP.

Potentially interested customers

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.

Edited by 🤖 GitLab Bot 🤖