Sign-in providers: GitLab, Gitea, Microsoft, Google, LDAP and custom OIDC

[dnviti]

Part of #166, alongside #167, #168 and #169. The other parts assume "whatever identity the user signed in with"; this is the issue that makes that phrase mean more than one thing.

Problem / Motivation

Sign-in is GitHub-only, and not optionally so: an installation cannot show a login page at all without a GitHub OAuth app, and who may enter is a list of GitHub accounts. An organisation that runs on Microsoft, Google, an LDAP directory, its own GitLab or its own OIDC provider either cannot use the product or has to hand GitHub accounts to people who otherwise have no reason to own one.

It also makes the identity the app holds an accident of one vendor. The name that lands on a user's commits, and the repository access their work gets, both come from the only provider there is — so a team whose code lives on a self-hosted GitLab still has to sign in through GitHub, and then authenticate to GitLab all over again by hand.

Goal

An administrator enables one or more sign-in providers — GitLab, Gitea, Microsoft, Google, LDAP, a custom OIDC provider, with more added over time — and users sign in with whichever they have. Where the provider is a git platform, that sign-in also gives the user's work its repository access. Where it is not, the app knows who they are and nothing more.

Scope

• Sign-in providers are configured by the installation's owner from Settings, with the same restrictions as the other installation-wide settings. Several can be enabled at once, and the sign-in page offers each of them.
• GitLab, Gitea, Microsoft, Google, LDAP and a generic OIDC provider ship alongside the existing GitHub sign-in, and adding another later does not mean reworking the ones already there.
• Who may sign in is decided per provider, in the way it is decided for GitHub today.
• One account can hold more than one connected identity, so a user can add another way of signing in — or connect a git platform for repository access — without ending up as two separate accounts with two separate sets of work.
• Signing in with a git platform gives the app that user's repository access, which is what lets their git tooling be set up for them. Signing in with an identity-only provider gives it their name and email and nothing else, and the difference is visible where it matters rather than discovered later.
• The name and email the app holds come from whichever provider the user signed in with, and are what git inside their containers is configured as.
• Existing installations keep working unchanged: the accounts that could sign in before still can, the first account remains the administrator, and nothing about GitHub sign-in changes for anyone already using it.
• Documentation covers setting up each provider, what each one gives the app, and how access is decided.

Non-goals

• Replacing or deprecating GitHub sign-in.
• Making sign-in optional, anonymous or password-based within the app itself.
• Roles or permission tiers beyond who may sign in and the existing administrator distinction.
• Deciding on the app's own that two identities belong to the same person.
• Synchronising accounts from a directory — creating and removing users automatically as the directory changes.

Security / Safety Considerations

• Two identities reporting the same email address are not the same person. Linking has to be a deliberate act by someone already able to prove both, never an automatic merge on a matching address — that is a well-worn route to taking over somebody else's account and everything in it.
• Provider configuration holds client secrets and directory credentials. It is administrator-only, stored with the same care as the installation's other secrets, and never handed back to the browser in full once saved.
• Losing access at the provider has to mean losing access here: an account removed from a directory or an allow-list must not keep working on the strength of a session issued earlier.
• A sign-in on a git platform now carries repository access into every container built for that user. What it will be used for has to be clear at the moment it is requested, and it must be used for nothing else.
• Enabling a provider widens who can get in, and the blast radius is the whole installation. The access rules need to be in place before it goes live, not after the first unexpected person signs in.

Acceptance Criteria

• An administrator can enable and configure GitLab, Gitea, Microsoft, Google, LDAP and a custom OIDC provider from Settings, and the configuration survives a restart.
• Several providers can be enabled at once, and the sign-in page offers each of them.
• A user signing in with any enabled provider gets an account carrying their name and email.
• Who may sign in can be restricted per provider, and someone outside that restriction is refused with a clear message.
• A user can connect a second identity to their existing account, and signing in with either reaches the same account and the same work.
• Two accounts are never merged automatically because they report the same email address.
• A user signed in with a git platform gets repository access with no extra step; a user signed in with an identity-only provider does not, and is told where that matters rather than hitting a failure.
• git inside a user's containers is configured with the name and email their own provider reports.
• An installation that uses GitHub sign-in today upgrades with no change: the same accounts sign in, and the same account remains the administrator.
• Revoking someone at the provider, or in the access rules, ends their access here rather than leaving an existing session alive.
• Documentation covers each provider's setup and what it gives the app.

Open Questions

• Should access be decidable by group or claim — an LDAP group, an OIDC claim, a GitLab group — or is a list of individuals enough for a first cut?
• Can a user connect a second identity themselves, or should an administrator do it for them?
• When a provider is disabled or removed, what happens to the projects and stored work of the people who signed in with it?