Re: [PATCH] Support pg_ident mapping for LDAP

From: Jacob Champion <pchampion(at)vmware(dot)com>
To: "magnus(at)hagander(dot)net" <magnus(at)hagander(dot)net>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Support pg_ident mapping for LDAP
Date: 2021-09-28 18:02:38
Message-ID: 707358a252b85a6b71c611e39dbe04e0db5860b2.camel@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2021-09-28 at 15:38 +0200, Magnus Hagander wrote:
> I'm a bit hesitant about the ldapuser libpq parameter. Do we really
> want to limit ourselves to just ldap, if we allow this? I mean, why
> not allow say radius or pam to also specify a different username for
> the external system? If we want to do that, now or in the future, we
> should have a much more generic parameter name, something like
> authuser?

I'd be on board with a more general option name.

So from the perspective of a SASL exchange, PGUSER would be the
authorization identity, and PGAUTHUSER, say, would be the
authentication identity. Is "auth" a clear enough prefix that users and
devs will understand what the difference is between the two?

| authn authz
---------+-----------------------------------
envvar | PGAUTHUSER PGUSER
conninfo | authuser user
frontend | conn->pgauthuser conn->pguser backend | port->auth_user port->user_name

> Why do we actually need ldap_map_dn? Shouldn't this just be what
> happens if you specify map= on an ldap connection?

For simple-bind setups, I think requiring users to match an entire DN
is probably unnecessary (and/or dangerous once you start getting into
regex mapping), so the map uses the bare username by default. My intent
was for that to have the same default behavior as cert maps.

Thanks,
--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-09-28 18:07:54 Re: Fixing WAL instability in various TAP tests
Previous Message Tom Lane 2021-09-28 17:27:11 Re: Fixing WAL instability in various TAP tests