Re: Proposal: Support custom authentication methods using hooks - Mailing list pgsql-hackers
| From | samay sharma |
|---|---|
| Subject | Re: Proposal: Support custom authentication methods using hooks |
| Date | |
| Msg-id | CAJxrbyyw5uRU5F+GZ7XxkU+LV95umn6Ab7BsicTZbO6ef8wxdw@mail.gmail.com Whole thread Raw |
| In response to | Re: Proposal: Support custom authentication methods using hooks (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
| Responses |
Re: Proposal: Support custom authentication methods using hooks
|
| List | pgsql-hackers |
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 think we are discussing two topics in this thread which in my opinion are orthogonal.
(a) Should we make authentication methods pluggable by exposing these hooks? - These will allow users to add plugins of their own to support whatever auth method they like. One immediate use case (and what prompted me to start looking at this) is Azure Active Directory integration which is a common request from Azure customers. We could also, over time, move some of our existing auth methods into extensions if we don’t want to maintain them in core.
Please note that these hooks do not restrict auth providers to use only plaintext auth methods. We could do SCRAM with secrets which are stored outside of Postgres using this auth plugin too. I can modify the test_auth_provider sample extension to do something like that as Andres suggested.
I don't see much point in that unless we deprecate *all* the
auth methods that transmit a cleartext password.
(b) Should we allow plaintext auth methods (and should we deprecate a few currently supported auth methods which use plaintext exchange)? - I think this is also a very important discussion but has many factors to consider independent of the hooks. Whatever decision is made here, we can impose that in auth.c later for plugins. For eg. allow plugins to only do plaintext stuff with SSL enabled (by checking if Port->ssl_in_use), or if we remove AUTH_REQ_PASSWORD, then plugins any way can’t use plaintext exchange with the client.
So, overall, if we are open to allowing plugins for auth methods, I can proceed to modify the test_auth_provider extension to use SCRAM and allow registering multiple providers for this specific change.
Regards,
Samay
pgsql-hackers by date: