Re: Proposal: Support custom authentication methods using hooks - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Proposal: Support custom authentication methods using hooks
Date
Msg-id 20220301213445.xrnwf3prxjaekimb@alap3.anarazel.de
Whole thread Raw
In response to Re: Proposal: Support custom authentication methods using hooks  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Hi,

On 2022-02-28 11:26:06 +0100, Peter Eisentraut wrote:
> We already have a variety of authentication mechanisms that support central
> management: LDAP, PAM, Kerberos, Radius.

LDAP, PAM and Radius all require cleartext passwords, so aren't a great
solution based on the concerns voiced in this thread. IME Kerberos is
operationally too complicated to really be used, unless it's already part of
the operating environment.


> What other mechanisms are people thinking about implementing using these
> hooks?

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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: range_agg with multirange inputs
Next
From: Andres Freund
Date:
Subject: Re: Proposal: Support custom authentication methods using hooks