Re: Salsa as authentication provider for Debian
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)
Reply to: