Hello, I'll try to summarise thread with the proposal to try wrapping it up and moving on. The proposal: [🔎] 20200405184610.GA581270@waldi.eu.org">https://lists.debian.org/[🔎] 20200405184610.GA581270@waldi.eu.org More details here: [🔎] 20200407140246.jpflo4zusyr2wowx@enricozini.org">https://lists.debian.org/[🔎] 20200407140246.jpflo4zusyr2wowx@enricozini.org I am not going into the advantages of the "Salsa as OIDC" provider approach, nor into summarising the brainstorming that happened about how this improvement could either combine with other things or could merge into a longer-term SSO strategy: I am only focusing on blockers. People in this thread have already started thinking about incremental improvements to this proposal and about other proposals, and that is *great*. I wouldn't want work to *end* at this: I want work to *begin* from this. The current situation with Single Sign-On in Debian sits in a spectrum between painful and useless. The painful side is nm.debian.org, where we force people to use it, leaving them no other choice. https://wiki.debian.org/DebianSingleSignOn does a great job of listing workarounds for all the shortcomings, but currently gaining access to nm.debian.org might be for some people the most complex, frustrating, and time consuming step towards becoming DD or DM. I have for long being considering taking contributors.debian.org offline: it's irresponsible to keep that service running if people can't log in to manage their accounts. The Salsa as OIDC provider proposal is something I'd rather work on, than taking the service offline. Other services in the Debian federation are instead implementing their own account management (like DebConf), or looking into directly authenticating via OIDC against Salsa anyway, like DebianSocial. I see using Salsa as OIDC provider as a mitigating step that would leave Debian with a useful Single Sign-On, without blocking further progress. Waiting longer means either closing services or scattering the federation into ad-hoc solutions. I solicited feedback to see if, for some reason, this step would make matters *worse* than the status quo, or make it *harder* to migrate onwards to something else. I'm summarising here the concerns that have been raised and how they've been addressed. * There are better solutions out there, like Keycloak or Lemon LDAP NG It would be great to have them. In the meantime, using Salsa as OIDC provider does not seem to be getting in the way of their potential adoption in the future. It does not seem that we would end up worse than we are now in that respect, and the next iteration of SSO in Debian is free to start at any time. See: [🔎] 20200407072834.2wcqldditbnnv2dw@enricozini.org">https://lists.debian.org/[🔎] 20200407072834.2wcqldditbnnv2dw@enricozini.org * There was work done on using Lemon LDAP NG plus Nacho[1] There was indeed, and Debian has never managed to put together enough energy to deploy it. I strongly want to thank Alexander Wirt and Birger Schacht for working on it, and sadly it never grew into something with enough support in the project to get deployed and maintained. This has stalled for long enough, and there is no indication that it could get deployed anytime soon. * Migrating to Salsa as OIDC provider would give us an imperfect but good enough local optimum, and we will get stuck in that Perfect is the enemy of good. Blocking a workable proposal for incremental improvement in case it turns out to be good enough, seems inconsistent to me give the current state of single sign-on in Debian. We are not proposing Salsa as the ultimate solution, but as a fix for the current situation, that does not prevent moving on to something else. See: [🔎] 20200409074438.wrb2csrsq2wzbssz@enricozini.org">https://lists.debian.org/[🔎] 20200409074438.wrb2csrsq2wzbssz@enricozini.org * There might be other solutions more secure than Gitlab I would find it hard to argue that the current sso.debian.org codebase is better than Gitlab, so we would be doing no worse than now. Additionally, the whole SSO ecosystem has always been considered somewhat untrusted and kept outside of the security perimeter of sensitive Debian operation, and this is not going to change with our proposal. See: [🔎] 20200410074045.yfwjnhbegm3dnw2e@enricozini.org">https://lists.debian.org/[🔎] 20200410074045.yfwjnhbegm3dnw2e@enricozini.org * User information may get locked into Gitlab's database format Gitlab has an API and enough user export features to easily extract anything from it, with the exception of passwords, as one would expect. * Are we losing support for client certs? How do service providers migrate? I will update sso.debian.org to consume OIDC auth instead of the current post-alioth user database, and act as a CA for the services that keep using client certificates for the time being. Services can implement OIDC authentication via either the features available in their programming stacks, or via apache modules. See: [🔎] 20200407165135.joe2vvl2mipcechj@enricozini.org">https://lists.debian.org/[🔎] 20200407165135.joe2vvl2mipcechj@enricozini.org * How about spam accounts on Salsa? The proposal makes no changes, for the better or the worse, in this respect. See: [🔎] 20200407182106.t772yp2ry3tl5fww@shell.thinkmo.de">https://lists.debian.org/[🔎] 20200407182106.t772yp2ry3tl5fww@shell.thinkmo.de * Non-DDs will eat up names in a namespace so far reserved for DDs I think it's not a problem if Debian contributors get to choose a username and keep it. I would argue it's an improvement to have usernames that don't have to change as one's membership status is gained or lost. See: [🔎] 20200408130828.izn7jdyufch7kfsc@enricozini.org">https://lists.debian.org/[🔎] 20200408130828.izn7jdyufch7kfsc@enricozini.org and: [🔎] 20200408131839.ispzcuzwwof2k7ke@enricozini.org">https://lists.debian.org/[🔎] 20200408131839.ispzcuzwwof2k7ke@enricozini.org * If we drop the requirement of having "-guest" for non-DD users on Salsa, how can one tell if a user is a DD? Waldi has a prototype ready for showing official membership status prominently and directly on a user's page, with information synced from nm.debian.org. Making sure that only current DDs have access to certain repositories is a problem that can be solved independently from account naming policies. * Will nm.d.o have a field which reflects the username on salsa? Yes, finally! It's been really painful not to have that so far. * How do we avoid namespace clashes between LDAP and Salsa? The two namespaces start in sync for non-guest accounts. nm.debian.org will forward the Salsa username to LDAP when new LDAP accounts are created, and will ask people who don't have an LDAP account, to choose a Salsa account name that is free in LDAP. This means that LDAP remains independent from Salsa and DSA remains fully in control over the user account namespace. It is the Salsa namespace that will have to adapt to what is free on LDAP's side, the moment someone with a Salsa account requests an account in LDAP. For people who get an account in LDAP and later want to rename their Salsa account, the option remains to register a new account to keep the old name locked. See: [🔎] 20200409072447.ci2xnvtnwv5as3vq@enricozini.org">https://lists.debian.org/[🔎] 20200409072447.ci2xnvtnwv5as3vq@enricozini.org and: [🔎] 20200409181701.3qqsn5sqq3xbu2ia@enricozini.org">https://lists.debian.org/[🔎] 20200409181701.3qqsn5sqq3xbu2ia@enricozini.org * Currently client certificates can be used to connect outside of browsers OIDC is a common standard, and there are standard ways to address this kind of use cases. Some services outside browsers (like dovecot) support OIDC. Services providing APIs normally offer API keys for interacting with the APIs. See: [🔎] 20200407182106.t772yp2ry3tl5fww@shell.thinkmo.de">http://lists.debian.org/[🔎] 20200407182106.t772yp2ry3tl5fww@shell.thinkmo.de * Proposed conclusion I could not see any reason why this proposal would make the situation *worse* than the status quo, or any reason this proposal would block further migration to something else in the future. I therefore consider it a useful iterative improvement over what we have, and see no reason to block it. I will start working with Waldi on getting it implemented, tracking progress at https://salsa.debian.org/debsso-team/oidc Anyone who would like to help, please get in touch! Enrico [1] https://salsa.debian.org/bisco-guest/nacho -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
Attachment:
signature.asc
Description: PGP signature