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

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: allowing "map" for password auth methods with clientcert=verify-full
Date: 2021-10-26 20:04:01
Message-ID: 0e0473ac-7f11-54fb-0ccb-a1c564e40a9d@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/26/21 3:26 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz(at)postgresql(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2021-10-26 20:43:22 Re: Feature request for adoptive indexes
Previous Message Stephen Frost 2021-10-26 20:02:55 Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.