Re: [PoC] Delegating pg_ident to a third party

Greetings,

* Jacob Champion (pchampion(at)vmware(dot)com) wrote:
> 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.

This is the part that I really wonder about also ... I've always viewed
pg_ident as being intended mainly for one-to-one kind of mappings and
not the "map a bunch of different users into the same role" that this
advocated for. Being able to have roles and memberships automatically
created is much more the direction that I'd say we should be going in,
so that in-database auditing has an actual user to go on and not some
generic role that could be any number of people.

I'd go a step further and suggest that the way to do this is with a
background worker that's started up and connects to an LDAP
infrastructure and listens for changes, allowing the system to pick up
on new roles/memberships as soon as they're created in the LDAP
environment. That would then be controlled by appropriate settings in
postgresql.conf/.auto.conf.

> Yeah, pg_ident is getting too cramped for this.

All that said, I do see how having the ability to call out to another
system for mappings may be useful, so I'm not sure that we shouldn't
consider this specific change and have it be specifically just for
mappings, in which case pg_ident seems appropriate.

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

I certainly don't think we should have this be limited to LDAP auth-
such an external mapping ability is suitable for any authentication
method that supports a mapping (thinking specifically of GSSAPI, of
course..). Not sure if that's what was meant above but did want to
make sure that was clear. The rest looks a lot more like pg_hba or
perhaps in-database privileges like roles/memberships existing or not
and CONNECT rights. I'm not really sold on the idea of adding yet even
more different ways to control authorization.

Thanks,

Stephen