Re: allowing "map" for password auth methods with clientcert=verify-full

On 10/26/21 18:16, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz(at)postgresql(dot)org> writes:
>> On 10/26/21 3:26 PM, Tom Lane wrote:
>>> I think this is conflating two different things: a mapping from the
>>> username given in the startup packet, and a mapping from the TLS
>>> certificate CN. Using the same keyword and terminology for both
>>> is going to lead to pain. I'm on board with the idea if we can
>>> disentangle that, though.
>> Hm, don't we already have that already when using "cert" combined with
>> the "map" parameter? This is the main reason I "stumbled" upon this
>> recommendation.
> I'm not exactly convinced that the existing design is any good.
> I'm suggesting that we stop and think about it before propagating
> it to a bunch of other use-cases.
>
> Per "21.2. User Name Maps", I think that the map parameter is supposed
> to translate from the startup packet's user name to the SQL role name.
> ISTM that what is in the cert CN might be different from either
> (particularly by perhaps having a domain name attached). So I'd be
> happier if there were a separate mapping available for the CN.
>
>

Possibly slightly off topic, but

The cert+map pattern is very useful in conjunction with pgbouncer. Using
it with an auth query to get the password pgbouncer doesn't even need to
have a list of users, and we in effect delegate authentication to
pgbouncer.

It would be nice to have + and @ expansion for the usernames in the
ident file, like there is for pg_hba.conf.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com