Re: Proposal: Support custom authentication methods using hooks

Hi,

On 2022-03-18 00:03:37 -0400, Stephen Frost wrote:
> On Thu, Mar 17, 2022 at 23:25 Andres Freund <andres(at)anarazel(dot)de> wrote:
> > It's imo a separate project to make the client side extensible. There's
> > plenty
> > of authentication methods that don't need any further client side support
> > than
> > the existing SASL (or password if OK for some use case) messages, which
> > most
> > clients (including libpq) already know.
> >
> > Of course the fact that libpq "only" speaks SCRAM-SHA-256 is a limit
> > (unless
> > you have server side access to clear text passwords, but brrr). But there's
> > plenty that can be done with that. Proxying auth via a central postgres
> > server
> > with the secrets, sharing secrets with other data stores also understanding
> > SCRAM-SHA-256, ...
> >
> > There definitely *also* are important authentication methods that can't be
> > implemented without further client side support. Some of those could
> > plausibly
> > be tackled on the protocol / libpq level in a way that they could be used
> > by
> > multiple authentication methods. Other authentication methods definitely
> > need
> > dedicated code in the client (although the protocol likely can be fairly
> > generic).
> >
> > Given that there's benefit from the server side extensibility alone, I
> > don't
> > see much benefit in tying the server side extensibility to the client side
> > extensibility.
>
>
> How are we going to reasonably test this then?

The test module in the patch is a good starting point.

> I also don’t think that I agree that it’s acceptable to only have the
> ability to extend the authentication on the server side as that implies a
> whole bunch of client-side work that goes above and beyond just
> implementing an authentication system if it’s not possible to leverage
> libpq (which nearly all languages out there use..). Not addressing that
> side of it also makes me concerned that whatever we do here won’t be
> right/enough/etc.

You're skipping over my point of everything that can be made to use
SASL-SCRAM-256 just working with the existing libpq? Again?

If you want to argue that somehow that communicating via SASL-SCRAM-256 from a
plugin is not a sufficient use-case, or that the API should be shaped more
specifically to just use SASL-SCRAM-256, fine. Argue it. Otherwise I don't
know what to do except ignore you.

Greetings,

Andres Freund