Le 05/04/2020 à 20:46, Bastian Blank a écrit : > 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
Hi, I can help if you want to use lemondap-ng (LLNG: https://lemonldap-ng.org https://tracker.debian.org/pkg/lemonldap-ng) > ## Current state > > - We have multiple user sources: > - Debian LDAP, > - Salsa (which syncs DD from Debian LDAP) and > - "Alioth" guest "LDAP" for sso.debian.org. LLNG can handle multiple sources (2 modules for that: user choice or automatic calculation using combination module) > - 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. This requires to change all services. Using a SSO is easier here: gatekeeper (KeyCloack) or handler (LLNG) permits to protect a web app without having to change to many things. LLNG handlers are directly included in Apache/Nginx configuration and provides HTTP-headers to the web app. Other way, LLNG is able to be a proxy between OAuth (OpenID-Connect) and any other SSO-language (CAS, SAML, OpenID-2) or handlers. The portal then becomes transparent > - 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? It's easy to integrate GitLab in SSO using SAML (or OIDC). It is perhaps more safe to manage users elsewhere (custom app) and make GitLab a slave of SSO system. LLNG provides a plugin engine for that. > 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. NB: KeyCloak is free but this needs to stay in last version, else you need a RedHat-SSO support. LLNG is totally free, written in Perl and JS; and Debian has a lot of Perl-Gurus ;-). I can give some accounts to demo platform: https://auth.openid.club/ [dev platform, so sometime broken...] or install an instance in a Debian machine if you want to try it. Resume of proposition: * all users managed by SSO; self-registration authorized with "-guest" in a distinct LDAP branch * GitLab becomes a slave of SSO using SAML (or OIDC) * other applications are protected by handlers/GateKeepers. If LLNG is chosen, just to add few lines in Nginx configuration * new applications can be protected using handlers, SAML, CAS, OIDC,... <as usual, sorry for my poor English> My 2 cents... Cheers, Xavier (yadd)