Re: Salsa as authentication provider for Debian
On Mon, 6 Apr 2020 20:38:59 +0200
Enrico Zini <enrico@enricozini.org> wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +0000, Luca Filipozzi wrote:
>
> > That said, please consider an approach that would see keycloak used as
> > an idenitity broker, allowing external users to create accounts using
> > social identities that are then promoted to full Debian identities (in
> > LDAP) if they complete the onboarding process. Could be used as
> > replacement for debsso, could be used for wiki, could be used for
> > debconf, could be used for salsa.
What does keycloak provide over something like lemonldap or similar tools?
> [...]
> and well known. Gitlab's codebase, while large and complex, is widely
> deployed, and we already have know-how about it in Debian.
I was previously involved with a company that audited various git-hosting
services. I'm stuck behind a very strict (saw it brutally enforced) NDA, so
please forgive the lack of specifics. Gitlab is a tool that gets many things
right, and many things wrong. Access control is an area where I have seen some
critical bugs. Some of those bugs lead me to not trust it as a non-internal
authentication source.
Security aside, and perhaps more importantly, is the vendor lock-in problem
that can be seen with Alioth. If that system were not being used as an
authentication source, then the whole migration would have been entirely
agnostic to such concerns and changing auth sources would never have come up.
Choosing to migrate to gitlab as an authentication source just introduces a
painful(?) migration for the sake of another similar migration in the future.
> I would not want to see a workable proposal that we could implement over
> the next two weeks and that we have the resources to maintain long-term,
> blocked by something that risks getting us stuck with sso.d.o for
> another bunch of years until we get it right, and possibly ending up
> being maintained long term by a team with a dwindling bandwidth and bus
> factor.
I was previously (before gitlab's deployment) lead to believe that the problem
was already being dealt with. Since this is still a problem, then I volunteer to
implement and maintain whatever solution is most appropriate.
Is there any summary of where those previous discussions lead and/or their
conclusions? I saw something about GSoC mentioned. Is there anything viable
which can be taken from that effort?
Also, please, don't focus on time to deployment. I'll do whatever we need in
order to implement a proper long-term solution. As you may have noticed- I take
my time to plan projects before execution. If anything, this is a change that
should involve more planning than anything else.
--
Michael Lustfield
Reply to: