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

From: Jacob Champion <pchampion(at)vmware(dot)com>
To: "jkatz(at)postgresql(dot)org" <jkatz(at)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: allowing "map" for password auth methods with clientcert=verify-full
Date: 2021-10-27 17:37:49
Message-ID: 82325a42f2adf77dc6f55f75bafbed583131c533.camel@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 the certificate CN to see if it matches the SQL role name.

Well, also to Tom's earlier point, though, this is a different sort of
mapping. Which "map" should we use if someone combines
clientcert=verify-full with an auth method which already uses a map
itself? Does the DBA want to map the auth name, the cert name, or both?

The current usermap support is piecemeal and I'd like to see it
completed, but I think you may be painting yourself into a corner if
you fix it in this way. (From a quick look at the patch, I'm also
worried that this happens to work by accident, but that may just be
FUD.)

> I think in the context of doing any new work, I'd step back and ask what
> problem is this solving? The main one I think of is an integration with
> a SSO system has a credential with an identifier that does not match
> it's credential in PostgreSQL? (That would be the case I was working on,
> though said case was borrowed from our docs). Are there other cases?
>
> That said, what would make it easier to manage it then? Maybe a lot of
> this is documenting and some expansion on what the pg_ident.conf file
> can do (per Andrew's suggestion). And maybe a new name for said file.

I agree that the authorization system is due for a tuneup, for what
it's worth. Some of the comments from Magnus on my LDAP patch [1] kind
of hinted in that direction as well, I think, even if my approach is
rejected in the end.

--Jacob

[1] https://www.postgresql.org/message-id/flat/1a61806047c536e7528b943d0cfe12608118ca31(dot)camel(at)vmware(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Brindle 2021-10-27 17:54:06 Re: [PATCH] Conflation of member/privs for predefined roles
Previous Message Bossart, Nathan 2021-10-27 17:34:13 Re: [PATCH] Conflation of member/privs for predefined roles