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
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
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
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
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
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
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
"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
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
"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
Hi,
Since PostgreSQL 12 (0516c61b756e39) we have allowed for the ability to
set "clientcert=verify-full" against various HBA authentication methods.
This provides the ability to provide "multi-factor authentication" e.g.
a client must provide both a valid certificate with a CN (or DN) that
ma
11 matches
Mail list logo
