Re: Proposal: Support custom authentication methods using hooks - Mailing list pgsql-hackers

Hi,

On 2022-08-03 17:21:58 -0400, Stephen Frost wrote:
> * Andres Freund (andres@anarazel.de) wrote:
> > On 2022-08-03 16:28:08 -0400, Stephen Frost wrote:
> > > Again, server-side only is not interesting and not a direction that
> > > makes sense to go in because it doesn't provide any way to have
> > > trust established in both directions, which is what all modern
> > > authentication methods do (certificates, kerberos, scram) and is what we
> > > should expect from anything new in this space.
> > 
> > As explained repeatedly before, that's plainly not true. The patch allows
> > e.g. to use the exact scram flow we already have, with the code we have for
> > that (e.g. using a different source of secret).  In fact the example extension
> > does so (starting in v3, from 2022-03-15):
> 
> Sure, thanks to the bespoke code in libpq for supporting SCRAM.  I don't
> think it makes sense to move the server-side code for that into an
> extension as it just makes work for a bunch of people.  Having a way to
> have the authenticator token for scram exist elsewhere doesn't strike me
> as unreasonable but that's not the same thing and is certainly more
> constrained in terms of what it's doing.

The question is: Why is providing that ability not a good step, even if
somewhat constrainted? One argument would be that a later "protocol level
extensibility" effort would require significant changes to the API - but I
don't think that'd be the case. And even if, this isn't a large extensibility
surface, so API evolution wouldn't be a problem.


> Further, I outlined exactly how extensability in this area could be
> achieved: use some good third party library that provides multiple SASL
> methods then just add support for that library to *PG*, on both the
> libpq and the server sides.

> What I don't think makes sense is adding extensibility to the server
> side, especially if it's through a 3rd party library, but then not
> adding support for that to libpq.  I don't follow what the rationale is
> for explicitly excluding libpq from this discussion.

The rationale is trivial: Breaking down projects into manageable, separately
useful, steps is a very sensible way of doing development. Even if we get
protocol extensibility, we're still going to need an extension API like it's
provided by the patchset. After protocol extensibility the authentication
extensions would then have more functions it could call to control the auth
flow with the client.


> To be clear- I'm not explicitly saying that we can only add
> extensibility with SCRAM, I'm just saying that whatever we're doing here
> to add other actual authentication methods we should be ensuring is done
> on both sides with a way for each side to authenticate the other side,
> as all of the modern authentication methods we have already do.

But *why* do these need to be tied together?


> > > If anything, the other auth methods should be ripped out entirely (password,
> > > md5, ldap, etc), but certainly not used as a basis for new work or a place
> > > to try and add new features, as they're all well known to have serious
> > > vulnerabilities.
> > 
> > I don't think we'd help users if we ripped out all those methods without a
> > replacement, but relegating them to contrib/ and thus requiring that they
> > explicitly get configured in the server seems like a decent step. But imo
> > that's a separate discussion.
> 
> We have a replacement for password and md5 and it's SCRAM.  For my 2c, I
> don't see the value in continuing to have those in any form at this
> point.  I concede that I may not get consensus on that but I don't
> really see how moving them to contrib would actually be helpful.

I'm much more on board with ripping out password and md5 than ldap, radius,
pam et al.

Greetings,

Andres Freund