I'm working through the responses linearly, so... On Tue, Apr 07, 2020 at 09:28:34AM +0200, Enrico Zini wrote: > On Mon, Apr 06, 2020 at 07:07:26PM +0000, Luca Filipozzi wrote: > > > > 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 read the response relating to an audit of gitlab source code, I would question whether gitlab is 'saft'. That said, we'd want similar attestations for LLNG or keycloak. Keycloak has been selected by a number of governments / unis / etc. That's not to say that they did code reviews; it is to say that it is receiving some adoption (which I think will grow). I know more about keycloak than LLNG, so I'll restrict my responses to Keycloak, SAML and OIDC (OpenID Connect). > > 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'. > > Yes :/ I think that's more or less where we are now, unfortunately, > after a year or more failing to find people to deploy and maintain > alternatives. I think people are stepping forward, albeit slowly. > On one hand, client certificate handling in browsers gets worse over > time, and the current sso solution is effectively running on people > collecting all sorts of workaround instructions in the excellent wiki > page at https://wiki.debian.org/DebianSingleSignOn I suggest that we move from client certificate-based authentication to SAML- or OIDC-based authentication. > On the other hand, signing in for non-DDs is a major hurdle that takes > literally weeks, when one can find out how to do it at all. We DDs care > little about that, it's Not Our Problem. That barrier makes joining > nm.debian.org to become a DD a challenge in itself. Other things like > managing one's own information on contributors.debian.org are just not > worth the challenge, and I'm planning to take contributors.d.o offline > soon, because I/we can't, ethically and legally, publish people's > information without giving those people a reasonable chance to control > it. With keycloak, we could: * allow people to create accounts locally in keycloak, and//or * allow people to create accounts tied to other identity providers (Gmail, etc.) This is the 'social-to-identity' concept where an organization wishes to make onboarding of new users as friendly as possible (let them use their existing credentials). If, later, they become a customer (i.e., Debian Developer), then you promote their account from 'social' to 'internal'). > > 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. > > Personally I'm interested in anything that works and that I can have a > very good confidence that somebody will maintain over time. > > I care about maintenance and sustainability more than about anything > else, because I'm the one who's been forced to set up and maintain SSO > in Debian mostly alone for 8 years, because everybody else walked away > from it and I could not. > > OIDC supports various authentication sources, and the Salsa plan > decouples OIDC from LDAP allowing them to evolve independently, removes > custom nonstandard components, and includes the option of migrating away > to something else in the future. In my understanding it enables > experimentation with other systems rather than blocking it. > > Question: is there something in the proposed Salsa plan that somehow > blocks experimenting with, introducing, or migrating to Keycloak in the > future? The further we go down one path, the harder, in my opinion, to change later. -- Luca Filipozzi
