Re: Salsa as authentication provider for Debian
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
Reply to: