Wrapping up the Salsa as OIDC provider proposal

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Wrapping up the Salsa as OIDC provider proposal

Enrico Zini
Hello,

I'll try to summarise thread with the proposal to try wrapping it up and
moving on.

The proposal: https://lists.debian.org/20200405184610.GA581270@...
More details here: https://lists.debian.org/20200407140246.jpflo4zusyr2wowx@...

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: https://lists.debian.org/20200407072834.2wcqldditbnnv2dw@...



* 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: https://lists.debian.org/20200409074438.wrb2csrsq2wzbssz@...



* 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: https://lists.debian.org/20200410074045.yfwjnhbegm3dnw2e@...



* 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: https://lists.debian.org/20200407165135.joe2vvl2mipcechj@...



* How about spam accounts on Salsa?

The proposal makes no changes, for the better or the worse, in this
respect.

See: https://lists.debian.org/20200407182106.t772yp2ry3tl5fww@...



* 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: https://lists.debian.org/20200408130828.izn7jdyufch7kfsc@...
and: https://lists.debian.org/20200408131839.ispzcuzwwof2k7ke@...



* 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: https://lists.debian.org/20200409072447.ci2xnvtnwv5as3vq@...
and: https://lists.debian.org/20200409181701.3qqsn5sqq3xbu2ia@...



* 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: http://lists.debian.org/20200407182106.t772yp2ry3tl5fww@...



* 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 <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wrapping up the Salsa as OIDC provider proposal

Ben Hutchings-3
On Fri, 2020-04-10 at 20:38 +0200, Enrico Zini wrote:
[...]
> * 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.
[...]

This seems to address the only concern I had with your proposal.
Thanks for all your work on SSO.

Ben.

--
Ben Hutchings
73.46% of all statistics are made up.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wrapping up the Salsa as OIDC provider proposal

Alex Muntada-2
In reply to this post by Enrico Zini
Hi Enrico,

> 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.

Let me publicly thank you for your work in sso, nm, contributors,
etc. I've been using these services for years and they have made
my life in Debian a lot easier that I can probably imagine.

Big kudos for you and all people involved!

> I therefore consider it a useful iterative improvement over
> what we have, and see no reason to block it.

FWIW, I like interative improvements and I fully support your
approach. Though I can understand that there are some concerns
in the long term, I'm totally up for small improvements even
if those end up making a longer path.

Sorry for not sharing this earlier and support your initiative.

Cheers!
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada <[hidden email]>
  ⢿⡄⠘⠷⠚⠋   Debian Developer 🍥 log.alexm.org
  ⠈⠳⣄⠀⠀⠀⠀


signature.asc (849 bytes) Download Attachment