Re: Proposal: Support custom authentication methods using hooks

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: samay sharma <smilingsamay(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposal: Support custom authentication methods using hooks
Date: 2022-03-02 08:32:26
Message-ID: a579b843-4b92-be7a-7417-085644805466@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-03-02 08:37:04 Re: Two noncritical bugs of pg_waldump
Previous Message shiy.fnst@fujitsu.com 2022-03-02 08:28:34 RE: Failed transaction statistics to measure the logical replication progress