Re: Proposal: Support custom authentication methods using hooks

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, 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-01 21:18:11
Message-ID: 139edb00-3ee8-6a34-a5a3-0465857d7a10@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/28/22 5:26 AM, Peter Eisentraut wrote:
> On 17.02.22 20:25, samay sharma wrote:
>> 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.
>
> 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.

OIDC is the big one that comes to mind.

Jonathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-03-01 21:27:00 Re: Allow async standbys wait for sync replication
Previous Message Jonathan S. Katz 2022-03-01 21:17:28 Re: Proposal: Support custom authentication methods using hooks