<note>
         <para>
          The encryption vector used will only be cryptographically
          strong if <productname>PostgreSQL</productname> is built with support for
          <productname>OpenSSL</productname>. In other cases, the transmission to the
          RADIUS server should only be considered obfuscated, not secured, and
          external security measures should be applied if necessary.
         </para>
         </note>
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><literal>radiusports</literal></term>
       <listitem>
        <para>
         The port numbers to connect to on the RADIUS servers. If no port
         is specified, the default RADIUS port (<literal>1812</literal>)
         will be used.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><literal>radiusidentifiers</literal></term>
       <listitem>
        <para>
         The strings to be used as <literal>NAS Identifier</literal> in the
         RADIUS requests. This parameter can be used, for example, to
         identify which database cluster the user is attempting to connect
         to, which can be useful for policy matching on
         the RADIUS server. If no identifier is specified, the default
         <literal>postgresql</literal> will be used.
        </para>
       </listitem>
      </varlistentry>

     </variablelist>
   </para>

   <para>
    If it is necessary to have a comma or whitespace in a RADIUS parameter
    value, that can be done by putting double quotes around the value, but
    it is tedious because two layers of double-quoting are now required.
    An example of putting whitespace into RADIUS secret strings is:
<programlisting>
host ... radius radiusservers="server1,server2" radiussecrets="""secret one"",""secret two"""
</programlisting>
   </para>
  </sect1>

  <sect1 id="auth-cert">
   <title>Certificate Authentication</title>

   <indexterm zone="auth-cert">
    <primary>Certificate</primary>
   </indexterm>

   <para>
    This authentication method uses SSL client certificates to perform
    authentication. It is therefore only available for SSL connections;
    see <xref linkend="ssl-openssl-config"/> for SSL configuration instructions.
    When using this authentication method, the server will require that
    the client provide a valid, trusted certificate.  No password prompt
    will be sent to the client.  The <literal>cn</literal> (Common Name)
    attribute of the certificate
    will be compared to the requested database user name, and if they match
    the login will be allowed.  User name mapping can be used to allow
    <literal>cn</literal> to be different from the database user name.
   </para>

   <para>
    The following configuration options are supported for SSL certificate
    authentication:
    <variablelist>
     <varlistentry>
      <term><literal>map</literal></term>
      <listitem>
       <para>
        Allows for mapping between system and database user names. See
        <xref linkend="auth-username-maps"/> for details.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>

   <para>
    It is redundant to use the <literal>clientcert</literal> option with
    <literal>cert</literal> authentication because <literal>cert</literal>
    authentication is effectively <literal>trust</literal> authentication
    with <literal>clientcert=verify-full</literal>.
   </para>
  </sect1>

  <sect1 id="auth-pam">
   <title>PAM Authentication</title>

   <indexterm zone="auth-pam">
    <primary>PAM</primary>
   </indexterm>

   <para>
    This authentication method operates similarly to
    <literal>password</literal> except that it uses PAM (Pluggable
    Authentication Modules) as the authentication mechanism. The
    default PAM service name is <literal>postgresql</literal>.
    PAM is used only to validate user name/password pairs and optionally the
    connected remote host