On Mon, Apr 06, 2020 at 08:38:59PM +0200, Enrico Zini 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. > > I don't know keycloak: what are the maintenance costs, and what would be > the benefits over time? > > Right now, with the proposal waldi just posted, we have very little to > no added maintenance cost, possibly negative maintenance cost once we > take sso.debian.org and the current handcrafted salsa subscription thing > offline. The amount of code deployed compared to the status quo would go > *down*. The user interface and user experience for the lot would be good > and well known. Gitlab's codebase, while large and complex, is widely > deployed, and we already have know-how about it in Debian.
Having just joined this conversation, the above is an argument that is difficult to refute: one can always argue that 'one in the hand is better than one in the bush'. > 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. Again, I'm just joining this conversation now. Keycloak is a RedHat-sponsored Java-based open-source project that provides a standards-based (SAML and OpenID) Identity Provider (IdP). It can also operate as an Identity Brokder (IdB). As an IdP, it can use an internal data store for users (database) or an external one (LDAP). It has a variety of workflows for user onboarding, user managed access, etc. As an IdB, it can be configured to allow 'social-to-identity' workflows so that users may begin their identity experience using their existing social identies (Gmail, Twitter, etc.). This is in addition to the users from the above IdP for Debian Developers. Service operators (websites, etc.) could then elect to accept all users or to require a role assignment / group membership to grant access to the service. Finally, should a user have started with a social identity but have successfully completed the Applicant process, then there are workflows that would allow users to merge their identities. My DSA colleagues asked for demo and I'm building that up, currently. I view this as a positive but not definitive step in the maintenance questions. I appreciate that the idea of using keycloak as an IdB requires everyone to shift perspective. Let me know if you have appetite (or not*) to discuss the above. Thanks, Luca * If not, then I'll stop advocating for this approach. There's the potential for a heated conversation, here, and I'm not up for that. -- Luca Filipozzi
