Re: allowing "map" for password auth methods with clientcert=verify-full
От | Jonathan S. Katz |
---|---|
Тема | Re: allowing "map" for password auth methods with clientcert=verify-full |
Дата | |
Msg-id | 0e0473ac-7f11-54fb-0ccb-a1c564e40a9d@postgresql.org обсуждение исходный текст |
Ответ на | Re: allowing "map" for password auth methods with clientcert=verify-full (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: allowing "map" for password auth methods with clientcert=verify-full
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: