Subject: Proposal: Support custom authentication methods using hooks

From: samay sharma <[email-masked]>
Date: Thu, 17 Feb 2022 11:25:50 -0800

Hi all,

I wanted to submit a patch to expose 2 new hooks (one for the
authentication check and another one for error reporting) in auth.c. These
will allow users to implement their own authentication methods for Postgres
or add custom logic around authentication.

A use case where this is useful are environments where you want
authentication to be centrally managed across different services. This is a
common deployment model for cloud providers where customers like to use
single sign on and authenticate across different services including
Postgres. Implementing this now is tricky as it requires syncing that
authentication method's credentials with Postgres (and that gets trickier
with TTL/expiry etc.). With these hooks, you can implement an extension to
check credentials directly using the authentication provider's APIs.

To enable this, I've proposed adding a new authentication method "custom"
which can be specified in pg_hba.conf and takes a mandatory argument
"provider" specifying which authentication provider to use. I've also moved
a couple static functions to headers so that extensions can call them.

Sample pg_hba.conf line to use a custom provider:

host    all             all             ::1/128                 custom
provider=test

As an example and a test case, I've added an extension named
test_auth_provider in src/test/modules which fetches credentials from
a pre-defined array. I've also added tap tests for the extension to test
this functionality.

One constraint in the current implementation is that we allow only one
authentication provider to be loaded at a time. In the future, we can add
more functionality to maintain an array of hooks and call the appropriate
one based on the provider name in the pg_hba line.

A couple of my tests are flaky and sometimes fail in CI. I think the reason
for that is I don't wait for pg_hba reload to be processed before checking
logs for error messages. I didn't find an immediate way to address that and
I'm looking into it but wanted to get an initial version out for
feedback on the approach taken and interfaces. Once those get finalized, I
can submit a patch to add docs as well.

Looking forward to your feedback.

Regards,

Samay

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 28 Feb 2022 11:26:06 +0100

On 17.02.22 20:25, samay sharma wrote:
> authentication to be centrally managed across different services. This 
> is a common deployment model for cloud providers where customers like to 
> use single sign on and authenticate across different services including 
> authentication method's credentials with Postgres (and that gets 
> trickier with TTL/expiry etc.). With these hooks, you can implement an 
> extension to check credentials directly using the 
> authentication provider's APIs.

We already have a variety of authentication mechanisms that support 
central management: LDAP, PAM, Kerberos, Radius.  What other mechanisms 
are people thinking about implementing using these hooks?  Maybe there 
are a bunch of them, in which case a hook system might be sensible, but 
if there are only one or two plausible ones, we could also just make 
them built in.

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Tue, 1 Mar 2022 16:18:11 -0500

On 2/28/22 5:26 AM, Peter Eisentraut wrote:
>> is a common deployment model for cloud providers where customers like 
>> to use single sign on and authenticate across different services 
>> including Postgres. Implementing this now is tricky as it requires 
>> syncing that authentication method's credentials with Postgres (and 
>> that gets trickier with TTL/expiry etc.). With these hooks, you can 
>> implement an extension to check credentials directly using the 

OIDC is the big one that comes to mind.

Jonathan

---

From: Andres Freund <[email-masked]>
Date: Tue, 1 Mar 2022 13:34:45 -0800

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