diff options
| author | Andrew Dunstan <andrew@dunslane.net> | 2021-03-29 15:31:22 -0400 |
|---|---|---|
| committer | Andrew Dunstan <andrew@dunslane.net> | 2021-03-29 15:49:39 -0400 |
| commit | 6d7a6feac48b1970c4cd127ee65d4c487acbb5e9 (patch) | |
| tree | 8728162431269b3ae654eddb1d3a8e1c99972ec3 /doc/src | |
| parent | efcc7572f532ea564fedc6359c2df43045ee7908 (diff) | |
| download | postgresql-6d7a6feac48b1970c4cd127ee65d4c487acbb5e9.tar.gz postgresql-6d7a6feac48b1970c4cd127ee65d4c487acbb5e9.zip | |
Allow matching the DN of a client certificate for authentication
Currently we only recognize the Common Name (CN) of a certificate's
subject to be matched against the user name. Thus certificates with
subjects '/OU=eng/CN=fred' and '/OU=sales/CN=fred' will have the same
connection rights. This patch provides an option to match the whole
Distinguished Name (DN) instead of just the CN. On any hba line using
client certificate identity, there is an option 'clientname' which can
have values of 'DN' or 'CN'. The default is 'CN', the current procedure.
The DN is matched against the RFC2253 formatted DN, which looks like
'CN=fred,OU=eng'.
This facility of probably best used in conjunction with an ident map.
Discussion: https://postgr.es/m/92e70110-9273-d93c-5913-0bccb6562740@dunslane.net
Reviewed-By: Michael Paquier, Daniel Gustafsson, Jacob Champion
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/client-auth.sgml | 24 |
1 files changed, 23 insertions, 1 deletions
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml index b420486a0af..951af49e9a4 100644 --- a/doc/src/sgml/client-auth.sgml +++ b/doc/src/sgml/client-auth.sgml @@ -598,7 +598,7 @@ hostnogssenc <replaceable>database</replaceable> <replaceable>user</replaceabl </para> <para> - In addition to the method-specific options listed below, there is one + In addition to the method-specific options listed below, there is a method-independent authentication option <literal>clientcert</literal>, which can be specified in any <literal>hostssl</literal> record. This option can be set to <literal>verify-ca</literal> or @@ -612,6 +612,28 @@ hostnogssenc <replaceable>database</replaceable> <replaceable>user</replaceabl the verification of client certificates with any authentication method that supports <literal>hostssl</literal> entries. </para> + <para> + On any record using client certificate authentication (i.e. one + using the <literal>cert</literal> authentication method or one + using the <literal>clientcert</literal> option), you can specify + which part of the client certificate credentials to match using + the <literal>clientname</literal> option. This option can have one + of two values. If you specify <literal>clientname=CN</literal>, which + is the default, the username is matched against the certificate's + <literal>Common Name (CN)</literal>. If instead you specify + <literal>clientname=DN</literal> the username is matched against the + entire <literal>Distinguished Name (DN)</literal> of the certificate. + This option is probably best used in conjunction with a username map. + The comparison is done with the <literal>DN</literal> in + <ulink url="https://tools.ietf.org/html/rfc2253">RFC 2253</ulink> + format. To see the <literal>DN</literal> of a client certificate + in this format, do +<programlisting> +openssl x509 -in myclient.crt -noout --subject -nameopt RFC2253 | sed "s/^subject=//" +</programlisting> + Care needs to be taken when using this option, especially when using + regular expression matching against the <literal>DN</literal>. + </para> </listitem> </varlistentry> </variablelist> |