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.ca...@vmware.com
