TL;DR: In Enrico's terms I'm an ACK not a NACK. I'm also trying to help people considering whether they have blocking objections think about the problems actually facing Debian. I'm noticing a bit of a conflict here between people who are familiar with Debian and people who are familiar with SSO. I think I have a bit of background in the SSO space over the years, and can perhaps try and bridge the gap of understanding. In a lot of SSO situations, the organization has a existing account lifecycle management strategy, and the SSO situation is assisting that. That is, the organization has a existing way to create accounts and deal with entitlements for those accounts. My day job uses Keycloak for that both for our own stuff and with customers. (We use a few other things in certain circumstances, including amusingly enough Gitlab in one instance) but generally tend toward Keycloak. However, that doesn't really describe the Debian situation. 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. 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. 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. so, a lot of people are jumping up and down talking about particular SSO strategies focusing on the SSO aspects of those strategies. 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. --Sam
Attachment:
signature.asc
Description: PGP signature