Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 06:23:29AM -0400, Sam Hartman wrote:
> Debian has two account life cycle work flows that we're reasonably happy
> with (or at least not proposing to change now).
>
> The first is the account life cycle for developers. DAM sends a signed
> ticket to keyring-maint and DSA, and accounts get created or locked.
> Developers send signed tickets to some combination of folks to deal with
> name changes.
>
> There's another flow. Contributors interact with DSA in some process I
> do not fully understand to get guest accounts on porter boxes etc.
The third flow being 'guests' in Debian LDAP.
> These account life cycle flows are too heavy-weight for several tasks
> that we find:
>
> * someone wants an account on salsa for hosting projects or interacting
> with projects there.
>
> * Someone wants to manage their contributors.debian.org info
>
> * Someone wants to enter the nm process. (This will eventually get to
> the heavy weight account life cycle, but we want starting the
> application to involve zero signed RT tickets)
>
> * People want to run services that consume Debian community accounts.
>
> So, it's not just that we need an SSO provider.
> we need a light weight account life cycle system that will fit into our
> SSO strategy.
With keycloak (or LLNG) set up as as a broker, then user account
self-creation is possible (caveat waldi's comments about attrs and
groups which requires more investigation).
> It also needs to eventually interact with nm, which will allow it to
> work with the existing account life cycle flow for developer accounts.
> But given Enrico's interest, I think it's safe to say that nm
> interactions are being considered.
With keycloak, when a user becomes a DD, we add an LDAP account and ask
the user to merge on next login via keycloak workflows or we use
keycloak APIs to merge for them.
> so, a lot of people are jumping up and down talking about particular SSO
> strategies focusing on the SSO aspects of those strategies.
No one is jumping, thank you.
> Where as what is the most important gaps for our project surround the
> account life cycle stuff.
>
> And for all its faults, Gitlab has a very easy story for this.
>
> You can maintain an account in gitlab with a username and password.
>
> In the long run you can also front gitlab with something else provided
> that you have a something else that does account lifecycle
> management.
>
> As a reminder, no one is talking about having DSA trust gitlab to
> control access to the archive or Debian machines. I think we all
> cringe thinking about that.
Well, given this DPL statement, shall I continue answering other emails
in this thread or no? That is the question now.
--
Luca Filipozzi
Reply to: