<literal>username@EXAMPLE.COM</literal> (or
        <literal>username/hostbased@EXAMPLE.COM</literal>, respectively),
        unless <literal>include_realm</literal> has been set to 0, in which case
        <literal>username</literal> (or <literal>username/hostbased</literal>)
        is what is seen as the system user name when mapping.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>krb_realm</literal></term>
      <listitem>
       <para>
        Sets the realm to match user principal names against. If this parameter
        is set, only users of that realm will be accepted.  If it is not set,
        users of any realm can connect, subject to whatever user name mapping
        is done.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </sect1>

  <sect1 id="auth-ident">
   <title>Ident Authentication</title>

   <indexterm>
    <primary>ident</primary>
   </indexterm>

   <para>
    The ident authentication method works by obtaining the client's
    operating system user name from an ident server and using it as
    the allowed database user name (with an optional user name mapping).
    This is only supported on TCP/IP connections.
   </para>

   <note>
    <para>
     When ident is specified for a local (non-TCP/IP) connection,
     peer authentication (see <xref linkend="auth-peer"/>) will be
     used instead.
    </para>
   </note>

   <para>
    The following configuration options are supported for <literal>ident</literal>:
    <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>
    The <quote>Identification Protocol</quote> is described in
    <ulink url="https://datatracker.ietf.org/doc/html/rfc1413">RFC 1413</ulink>.
    Virtually every Unix-like
    operating system ships with an ident server that listens on TCP
    port 113 by default. The basic functionality of an ident server
    is to answer questions like <quote>What user initiated the
    connection that goes out of your port <replaceable>X</replaceable>
    and connects to my port <replaceable>Y</replaceable>?</quote>.
    Since <productname>PostgreSQL</productname> knows both <replaceable>X</replaceable> and
    <replaceable>Y</replaceable> when a physical connection is established, it
    can interrogate the ident server on the host of the connecting
    client and can theoretically determine the operating system user
    for any given connection.
   </para>

   <para>
    The drawback of this procedure is that it depends on the integrity
    of the client: if the client machine is untrusted or compromised,
    an attacker could run just about any program on port 113 and
    return any user name they choose. This authentication method is
    therefore only appropriate for closed networks where each client
    machine is under tight control and where the database and system
    administrators operate in close contact. In other words, you must
    trust the machine running the ident server.
    Heed the warning:
    <blockquote>
     <attribution>RFC 1413</attribution>
     <para>
      The Identification Protocol is not intended as an authorization
      or access control protocol.
     </para>
    </blockquote>
   </para>

   <para>
    Some ident servers have a nonstandard option that causes the returned
    user name to be encrypted, using a key that only the originating
    machine's administrator knows.  This option <emphasis>must not</emphasis> be
    used when using the ident server with <productname>PostgreSQL</productname>,
    since <productname>PostgreSQL</productname> does not have any way to decrypt the
    returned string to determine the actual user name.
   </para>
  </sect1>

  <sect1