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

From Jonathan S. Katz
Subject Re: allowing "map" for password auth methods with clientcert=verify-full
Date
Msg-id 0e0473ac-7f11-54fb-0ccb-a1c564e40a9d@postgresql.org
Whole thread Raw
In response to Re: allowing "map" for password auth methods with clientcert=verify-full  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: allowing "map" for password auth methods with clientcert=verify-full  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 10/26/21 3:26 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> With certificate-based authentication methods and other methods, we
>> allow for users to specify a mapping in pg_ident, e.g. if one needs to
>> perform a rewrite on the CN to match the username that is specified
>> within PostgreSQL.
> 
>> It seems logical that we should allow for something like:
>>     hostssl all all all scram-sha-256 clientcert=verify-full map=map
>> so we can accept certificates that may have CNs that can be mapped to a
>> PostgreSQL user name.
> 
> 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.

Based on what you say and if we're continuing with this functionality, 
would solving the conflation be a matter of primarily documentation?

Thanks,

Jonathan

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
Next
From: Tomas Vondra
Date:
Subject: Re: Feature request for adoptive indexes