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
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. |