| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
| 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 19:26:08 |
| Message-ID: | 113078.1635276368@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mahendra Singh Thalor | 2021-10-26 19:31:36 | Re: Replication & recovery_min_apply_delay |
| Previous Message | Jonathan S. Katz | 2021-10-26 18:59:19 | allowing "map" for password auth methods with clientcert=verify-full |