Re: Proposal: Support custom authentication methods using hooks

Greetings,

* 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'. There even existed a plugin mechanism (PAM) before
many of them, and they weren't able implemented using 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.

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

Thanks,

Stephen