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
