Re: Proposal: Support custom authentication methods using hooks

Hi,

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):
Check 0002 from
https://www.postgresql.org/message-id/CAJxrbyxgFzfqby%2BVRCkeAhJnwVZE50%2BZLPx0JT2TDg9LbZtkCg%40mail.gmail.com

If you're ideologically opposed to allowing extensibility in this specific
area: Say so, instead of repeating this bogus argument over and over.

> 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.

> I also don't agree that this makes sense as an extension as we don't
> have any way for extensions to make changes in libpq or psql, again
> leading to the issue that it either can't be exercised or we create some
> dependency on an external SASL library for libpq but object to having
> that same dependency on the server side, which doesn't seem sensible to
> me. Requiring admins to jump through hoops to install an extension
> where we have such a dependency on a library anyway doesn't make sense
> either.

This argument doesn't make a whole lot of sense to me - as explained above you
can use the existing scram flow for plenty usecases. I'd be a bit more
convinced if you'd argue that the extension API should just allow providing a
different source of secrets for the existing scram flow (I'd argue that that's
not the best point for extensibility, but that'd be more a question of taste).

Greetings,

Andres Freund