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

[Jonathan S. Katz]

Hi,






It seems logical that we should allow for something like:

        hostssl all all all scram-sha-256 clientcert=verify-full map=map



Currently we can't do this, as one will get the error:

> authentication option "map" is only valid for authentication methods
> ident, peer, gssapi, sspi, and cert







Thanks,

Jonathan

diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 3be8778d21..b53b2925e0 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1713,8 +1713,10 @@ parse_hba_auth_opt(char *name, char *val, HbaLine 
*hbaline,
                        hbaline->auth_method != uaPeer &&
                        hbaline->auth_method != uaGSS &&
                        hbaline->auth_method != uaSSPI &&
-                       hbaline->auth_method != uaCert)
-                       INVALID_AUTH_OPTION("map", gettext_noop("ident, peer, 
gssapi, sspi, and cert"));
+                       hbaline->auth_method != uaCert &&
+                       hbaline->auth_method != uaSCRAM &&
+                       hbaline->auth_method != uaMD5)
+                       INVALID_AUTH_OPTION("map", gettext_noop("ident, peer, 
gssapi, sspi, cert, scram-sha-256, and md5"));
                hbaline->usermap = pstrdup(val);
        }
        else if (strcmp(name, "clientcert") == 0)

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 matches the user account, as well as a separate authentication challenge (e.g. a password). 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. so we can accept certificates that may have CNs that can be mapped to a PostgreSQL user name. I propose the below patch to add the currently supported password methods, scram-sha-256 + md5 to allow for the "map" parameter to be used. I hesitate to add md5 given we're trying to phase it out, so open to debate there. With my testing, this does work when you specify clientcert=verify-full: PostgreSQL will correctly map the certificate. If you do not have clientcert=verify-full, the mapping appears to do nothing. If this seems acceptable/valid, I'll add the appropriate documentation and whatever else may be required.

OpenPGP_signature
Description: OpenPGP digital signature