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

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