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