Hi,
On 2022-03-18 00:45:49 -0400, Stephen Frost wrote:
> > 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?
> The plan is to make scram pluggable on the client side? That isn’t what’s
> been proposed here that I’ve seen.
Libpq and many other drivers already speaks SASL-SCRAM-256. If you're
implementing an authentication method that wants to store secrets outside of
postgres (centrally in another postgres instance, ldap, mysql or whatnot) you
don't need to make scram pluggable client-side. From the perspective of the
client it'd look *exactly* like the normal auth flow with the server.
What's proposed here is not really about adding new authentication protocols
between FE/BE (although some *limited* forms of that might be possible). It's
primarily about using the existing FE/BE authentication exchanges
(AUTH_REQ_{PASSWORD,SASL*,...}) to validate against something other than the
builtin pg_authid.rolpassword. Because drivers already know those
authentication exchanges, it doesn't need to learn new tricks.
As I said in
https://www.postgresql.org/message-id/20220318032520.t2bcwrnterg6lq6g%40alap3.anarazel.de
when describing the above, that's not enough to implement every desireable
authentication method - but there's real use-cases where using the existing
SASL-SCRAM-256 is sufficient.
> I also wasn’t aware that we felt that it’s acceptable to just ignore other
> committers.
I'm not talking about going ahead and committing. Just not continuing
discussing this topci and spending my time more fruitfully on something else.
Greetings,
Andres Freund
