Salsa as authentication provider for Debian
Dear Debian fellows
Enrico (for NM and sso.debian.org) and I (for Salsa) intend to implement the
following plan. At the same time we declare the following services as EOL:
- sso.debian.org and
- parts of the Salsa self service interface.
We asked DPL, NM, DSA and the Salsa admins already for feedback about what we
intend to do.
We mostly got positive feedback from them, with some reservations about the
user renames.
We did not receive a response from DSA to date. We only got some personal
remarks from jcristau and weasel on IRC. They don't want to handle Salsa
differently and store information. Also they declared worry about user name
conflicts.
We did some changes to remedy those, so we scrapped the changes we had asked
DSA to do and will check for name conflicts in nm.debian.org before sending
user creation requests to DSA.
Regards,
Enrico and Bastian
## Current state
- We have multiple user sources:
- Debian LDAP,
- Salsa (which syncs DD from Debian LDAP) and
- "Alioth" guest "LDAP" for sso.debian.org.
- We have no way to rename users, neither within the Debian LDAP, nor Salsa.
Renames require a complete new user.
- A person transitioning between non-DD and DD needs a new user and loses all
state.
- Guest users on Salsa are forced to end with `-guest`.
## Highlevel plan
- Salsa becomes primary source of user info and authentication for secondary
services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing
sso.debian.org.
- Salsa allows user renames and drops namespace rules for users (i.e., no more
requirement for -guest suffix).
- nm.debian.org uses Salsa usernames by default to populate LDAP usernames when
creating accounts, and stores OIDC subject to strongly correlate between
Salsa and Debian LDAP users.
## Fixed problems
- We get a user source everyone can use both as service provider and user.
- Users can rename themselves before becoming DDs, and retain all information
both on Salsa and on other services. This also works while transitioning
between non-DD and DD, and back.
## Corner cases
The Salsa and LDAP databases don't need to be in sync:
- The interaction between the two namespaces only happens when the Salsa
namespace provides the value for a new DD's LDAP UID. By using salsa as
default for LDAP UID, we keep the names roughly in sync for convenience
- Conflicts can happen when a prospective new DD has a Salsa username that
corresponds to an already allocated LDAP uid, and they can be detected and
handled on nm.debian.org before account creation: people can be told that
their salsa username is already in use in LDAP, and get a chance to rename it.
- If one renames their Salsa account after becoming DD, someone else could
start using the old name and exploit the confusion. This would be a rare
occurrence, and Salsa admins can lock the malicious account if that happens.
People can rename their account on Salsa even after the account exists in LDAP,
since the OIDC identifying information would be the subject, which is the
GitLab internal user ID, which is preserved across renames.
nm.debian.org will provide official membership information to Salsa, so the
Debian group on Salsa will remain, showing DD status.
## Required changes
### Salsa
- Enable sign-on and allow user rename (last step).
- Remove user support from Salsa self service interface.
### Salsa user sync
- Use nm.debian.org as data source for official DD status.
- Add/remove @debian.org e-mail addresses in user information, from
nm.debian.org
### nm.debian.org
- Support OIDC to get subject, username, display name and e-mail address for
users.
- Supply information about DD for consumption by Salsa user sync.
- Check for username conflicts.
### sso.debian.org
- Authenticate via OIDC to provide certificate management for a transition
period, until all sso-using services have migrated to OIDC
## Exit plan
Should GitLab and/or Salsa become unmaintainable, what do we need to migrate
away?
We can export username, e-mail addresses, group membership and OIDC subject
into a new system. Passwords may not be portable.
Most OIDC using services allow multiple authentication providers out of the
box, so adding a new authentication system can be straightforward. If replacing
Salsa, the issue would be to map user-related information from Salsa's OIDC
subject to whatever the new system uses, and data can be exported from Salsa to
help creating such mapping lists services can use to transition.
--
You canna change the laws of physics, Captain; I've got to have thirty minutes!
Reply to: