Re: allowing "map" for password auth methods with clientcert=verify-full - Mailing list pgsql-hackers

From Tom Lane
Subject Re: allowing "map" for password auth methods with clientcert=verify-full
Date
Msg-id 176308.1635286594@sss.pgh.pa.us
Whole thread Raw
In response to Re: allowing "map" for password auth methods with clientcert=verify-full  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: allowing "map" for password auth methods with clientcert=verify-full  (Andrew Dunstan <andrew@dunslane.net>)
Re: allowing "map" for password auth methods with clientcert=verify-full  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
"Jonathan S. Katz" <jkatz@postgresql.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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Feature request for adoptive indexes
Next
From: Tom Lane
Date:
Subject: Re: Assorted improvements in pg_dump