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!
