[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: