Re: Proposal: Support custom authentication methods using hooks

From: samay sharma <smilingsamay(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposal: Support custom authentication methods using hooks
Date: 2022-02-23 22:11:33
Message-ID: CAJxrbyx945vpc030dHdx+SpZ36v-mR8Le=XLoJfQKOy9pr97kw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

On Thu, Feb 17, 2022 at 11:25 AM samay sharma <smilingsamay(at)gmail(dot)com>
wrote:

> 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.
>

I wanted to submit a v2 of my patches.

To fix the flaky tests, I decided to avoid checking the log files for
pg_hba reload errors and rely on the output of pg_hba_file_rules. While
doing that, I found two bugs (in my code) which were causing the custom
provider line to not be outputted correctly in pg_hba_file_rules.

This updated patch-set fixes those bugs and also uses pg_hba_file_rules to
check for errors arising due to improper configuration. After these
changes, I've stopped seeing CI failures.

Looking forward to feedback on the overall change and the approach taken.

Regards,
Samay

>
> Looking forward to your feedback.
>
>
> Regards,
>
> Samay
>

Attachment Content-Type Size
v2-0003-Add-tests-for-test_auth_provider-extension.patch application/octet-stream 6.1 KB
v2-0001-Add-support-for-custom-authentication-methods.patch application/octet-stream 11.3 KB
v2-0002-Add-sample-extension-to-test-custom-auth-provider.patch application/octet-stream 3.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2022-02-23 22:46:50 Re: Some optimisations for numeric division
Previous Message Euler Taveira 2022-02-23 22:05:58 Re: logical decoding and replication of sequences