Re: Proposal: Support custom authentication methods using hooks

Hi,

On 2022-03-17 14:03:31 -0400, Stephen Frost wrote:
> * Andres Freund (andres(at)anarazel(dot)de) wrote:
> > On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > > Looking at the existing authentication methods
> > >
> > > # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
> > > # "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert".
> > >
> > > how many of these could have been implemented using a plugin mechanism that
> > > was designed before the new method was considered? Probably not many.
> >
> > trust, reject, md5, password, ident, peer, pam, ldap, radius look trivially
> > possible. I think sspi is doable as well, but I don't know it well enough to
> > be confident. gss without transport encryption could have as well, I
> > think. Even scram-sha-256 looks possible, although that'd have been a good bit
> > harder. Where do you see the problems?
>
> I agree with Peter and don't feel like the above actually answered the
> question in any fashion. The question wasn't "which auth methods could
> be implemented using these new set of hooks?" but rather- which could
> have been implemented using a plugin mechanism that was designed
> *before* the new method was considered? The answer to that is
> 'basically none'.

I fail to see how you come to that conclusion.

> There even existed a plugin mechanism (PAM) before many of them, and they
> weren't able implemented using it.

That's nonsensical. PAM is a platform specific API to start with - so it
doesn't make sense to implement additional postgres authentication mechanism
with it. It also wasn't added to postgres as a base mechanism for extensible
authentication. And it's fundamentally restricted in the kind of secret
exchanges that can be implemented with it.

> That's entirely the point- while this might be an interesting way to
> redesign what we have now, should we feel that's useful to do (I don't and
> think it would be an actively bad thing for the project to try and do...)
> there's no reason to believe that it'll actually be useful for the *next*
> auth method that comes along.

What concrete limitation do you see in the API? It basically gives you the
same powers as writing something in auth.c directly. And due to AUTH_REQ_SASL*
we have fairly extensible ways of exchanging authentication data.

> > Only stuff tying into transport encryption is clearly not doable via the
> > proposed API, but that's hardly the fault of an authentication API?
>
> This is absolutely the wrong way to look at it. The authentication
> methods that are coming along today are designed to tie into the
> transport encryption because that's *needed* to avoid MITM attacks. I'd
> much rather we generally avoid including ones that don't support that
> and we certainly shouldn't be trying to build a generic system which
> explicitly doesn't support it.

So you're saying that any authentication API needs to come together with a
runtime extendable secure transport mechanism? That feels like raising the bar
ridiculously into the sky. If we want to add more transport mechanisms - and
I'm not sure we do - that's a very sizable project on its own. And
independent.

Note that you *can* combine existing secure transport mechanisms with the
proposed API. You can use Port->{ssl,gss,peer_cn,...} to query information and
do further openssl etc calls.

Greetings,

Andres Freund