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

2021-11-30 Thread Jacob Champion
On Mon, 2021-11-08 at 15:32 -0500, Stephen Frost wrote: > Where does that leave us with what Jonathan is suggesting though? For > my 2c, we shouldn't allow 'map=' to be used for scram or md5 because > it'll just confuse users, until and unless we actually do the PGAUTHUSER > thing and then we can

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

2021-11-08 Thread Stephen Frost
Greetings, * Jacob Champion (pchamp...@vmware.com) wrote: > On Wed, 2021-10-27 at 12:53 -0400, Jonathan S. Katz wrote: > > The patch I propose just layers on top of the existing functionality -- > > you could even argue that it's "fixing a bug" that we did not add the > > current "map" support

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

2021-10-27 Thread Jacob Champion
On Wed, 2021-10-27 at 12:53 -0400, Jonathan S. Katz wrote: > The patch I propose just layers on top of the existing functionality -- > you could even argue that it's "fixing a bug" that we did not add the > current "map" support for the case of "clientcert=verify-full" given we > do introspect

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

2021-10-27 Thread Jonathan S. Katz
On 10/27/21 12:14 PM, Jacob Champion wrote: On Tue, 2021-10-26 at 18:16 -0400, Tom Lane wrote: Per "21.2. User Name Maps", I think that the map parameter is supposed to translate from the startup packet's user name to the SQL role name. I may have misunderstood what you wrote, but IIUC the sta

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

2021-10-27 Thread Jacob Champion
On Wed, 2021-10-27 at 10:12 -0400, Andrew Dunstan wrote: > Possibly slightly off topic, but > > The cert+map pattern is very useful in conjunction with pgbouncer. Using > it with an auth query to get the password pgbouncer doesn't even need to > have a list of users, and we in effect delegate auth

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

2021-10-27 Thread Jacob Champion
On Tue, 2021-10-26 at 18:16 -0400, Tom Lane wrote: > Per "21.2. User Name Maps", I think that the map parameter is supposed > to translate from the startup packet's user name to the SQL role name. I may have misunderstood what you wrote, but IIUC the startup packet's user name _is_ the SQL role na

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

2021-10-27 Thread Andrew Dunstan
On 10/26/21 18:16, Tom Lane wrote: > "Jonathan S. Katz" writes: >> On 10/26/21 3:26 PM, Tom Lane wrote: >>> 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 ter

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

2021-10-26 Thread Tom Lane
"Jonathan S. Katz" writes: > On 10/26/21 3:26 PM, Tom Lane wrote: >> 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 pa

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

2021-10-26 Thread Jonathan S. Katz
On 10/26/21 3:26 PM, Tom Lane wrote: "Jonathan S. Katz" 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

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

2021-10-26 Thread Tom Lane
"Jonathan S. Katz" 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