Re: Proposal: Support custom authentication methods using hooks

Greetings,

* Peter Eisentraut (peter(dot)eisentraut(at)enterprisedb(dot)com) wrote:
> On 01.03.22 22:34, Andres Freund wrote:
> >The cases I've heard about are about centralizing auth across multiple cloud
> >services. Including secret management in some form. E.g. allowing an
> >application to auth to postgres, redis and having the secret provided by
> >infrastructure, rather than having to hardcode it in config or such.
> >
> >I can't see application developers configuring kerberos and I don't think
> >LDAP, PAM, Radius are a great answer either, due to the plaintext requirement
> >alone? LDAP is pretty clearly dying technology, PAM is fragile complicated C
> >stuff that's not portable across OSs. Radius is probably the most realistic,
> >but at least as implemented doesn't seem flexible enough (e.g. no access to
> >group memberships etc).
> >
> >Nor does baking stuff like that in seem realistic to me, it'll presumably be
> >too cloud provider specific.
>
> Let's gather some more information on this. PostgreSQL should support the
> authentication that many people want to use out of the box. I don't think
> it would be good to be at a point where all the built-in methods are
> outdated and if you want to use the good stuff you have to hunt for plugins.
> The number of different cloud APIs is effectively small. I expect that
> there are a lot of similarities, like they probably all need support for
> http calls, they might need support for caching lookups, etc. OIDC was
> mentioned elsewhere. That's a standard. Is that compatible with any cloud
> providers? Would that be enough for many users?

I tend to agree with this, and to that end I'd argue that we should
probably be working to drop support for things like PAM, with
appropriate code replacing any useful capabilities that folks were using
it for (which would also mean it'd work across all the OS's we support,
which would be nice..).

Thanks,

Stephen