From: | Jacob Champion <pchampion(at)vmware(dot)com> |
---|---|
To: | "peter(dot)eisentraut(at)enterprisedb(dot)com" <peter(dot)eisentraut(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PoC] Delegating pg_ident to a third party |
Date: | 2022-01-03 16:46:16 |
Message-ID: | 0e0c038ab962c3f6dab00934fe5ae1ae115f44c0.camel@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2021-12-17 at 10:06 +0100, Peter Eisentraut wrote:
> On 17.12.21 00:48, Jacob Champion wrote:
> > WDYT? (My responses here will be slower than usual. Hope you all have a
> > great end to the year!)
>
> Looks interesting. I wonder whether putting this into pg_ident.conf is
> sensible. I suspect people will want to eventually add more features
> around this, like automatically creating roles or role memberships, at
> which point pg_ident.conf doesn't seem appropriate anymore.
Yeah, pg_ident is getting too cramped for this.
> Should we have a new file for this? Do you have any further ideas?
My experience with these configs is mostly limited to HTTP servers.
That said, it's pretty hard to beat the flexibility of arbitrary key-
value pairs inside nested contexts. It's nice to be able to say things
like
Everyone has to use LDAP auth
With this server
And these TLS settings
Except admins
who additionally need client certificates
with this CA root
And Jacob
who isn't allowed in anymore
Are there any existing discussions along these lines that I should take
a look at?
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-01-03 16:50:12 | Re: [PATCH] pg_stat_toast v0.4 |
Previous Message | Andrey Borodin | 2022-01-03 16:36:53 | Re: Index-only scans vs. partially-retrievable indexes |