root/traduc/trunk/postgresql/client-auth.xml

<?xml version="1.0" encoding="ISO-8859-15"?>
<!-- Dernière modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->
<!-- SAS : 20070320, PG8.2.3 -->

<chapter id="client-authentication">
<title>Authentification du client</title>

 <indexterm zone="client-authentication">
 <primary>authentification client</primary> </indexterm>

 <para>Quand une application client se connecte au serveur de bases de données,
  elle indique le nom de l'utilisateur de base de données
  à utiliser pour la connexion, de la même façon qu'on se connecte à un ordinateur
  Unix sous un nom d'utilisateur particulier. Au sein de l'environnement SQL, le
  nom d'utilisateur de la base de données active détermine les droits
  régissant l'accès aux objets de la base de données &mdash; voir le
  <xref linkend="user-manag"/> pour plus d'informations. Ainsi, il est essentiel de
  limiter le nombre de bases de données auxquelles les utilisateurs peuvent se
  connecter.</para>

 <note>
  <para>
   Comme expliqué dans le <xref linkend="user-manag"/>,
   <productname>PostgreSQL</productname> gère les droits par l'intermédiaire
   des <quote>rôles</quote>. Dans ce chapitre, le terme 
   <firstterm>utilisateur de bases de données</firstterm> est utilisé pour
   signifier <quote>rôle disposant du droit <literal>LOGIN</literal></quote>.
  </para>
 </note>

 <para>L'<firstterm>authentification</firstterm> est le processus par lequel le
  serveur de bases de données établit l'identité du client et, par extension,
  détermine si l'application client (ou l'utilisateur qui l'utilise) est
  autorisée à se connecter avec le nom d'utilisateur de bases de données
  indiqué.</para>

 <para><productname>PostgreSQL</productname> offre quantité de méthodes
  d'authentification différentes. La méthode utilisée pour authentifier une connexion
  client particulière peut être sélectionnée d'après l'adresse (du client), la base de
  données et l'utilisateur.</para>

 <para>Les noms d'utilisateur de bases de données sont
  séparés de façon logique des noms d'utilisateur du système d'exploitation sur
  lequel tourne le serveur. Si tous les utilisateurs d'un serveur donné ont
  aussi des comptes sur la machine serveur, il peut être pertinent d'attribuer
  aux utilisateurs de bases de données des noms qui correspondent à ceux
  des utilisateurs du système d'exploitation. Cependant, un serveur qui
  accepte des connexions
  distantes peut avoir des utilisateurs de bases de données dépourvus de
  compte correspondant sur le système d'exploitation. Dans ce cas, aucune
  correspondance entre les noms n'est nécessaire.</para>

 <sect1 id="auth-pg-hba-conf"> <title>Le fichier <filename>pg_hba.conf</filename></title>

  <indexterm zone="auth-pg-hba-conf"> <primary>pg_hba.conf</primary>
</indexterm>

  <para>L'authentification du client est contrôlée par un fichier,
   traditionnellement nommé <filename>pg_hba.conf</filename> et situé dans le
   répertoire data du groupe de bases de données, par exemple
   <filename>/usr/local/pgsql/data/pg_hba.conf</filename> (<acronym>HBA</acronym>
   signifie <quote>host-based authentication</quote>&nbsp;: authentification
   fondée sur l'hôte.) Un
   fichier <filename>pg_hba.conf</filename> par défaut est installé lorsque le
   répertoire data est initialisé par <command>initdb</command>. Néanmoins, il
   est possible de placer le fichier de configuration de l'authentification
   ailleurs&nbsp;; voir le paramètre de configuration <xref linkend="guc-hba-file"/>.
  </para>

  <para>
   Le format général du fichier <filename>pg_hba.conf</filename> est un
   ensemble d'enregistrements, un par ligne. Les lignes vides sont ignorées tout
   comme n'importe quel texte placé après le caractère de commentaire
   <literal>#</literal>. Un enregistrement est constitué d'un certain nombre de
   champs séparés par des espace et/ou des tabulations. Les champs peuvent contenir
   des espaces si la valeur du champ est mise entre guillemets. Un enregistrement
   ne peut pas s'étendre sur plusieurs lignes.</para>

  <para>
   Chaque enregistrement précise un type de connexion, une plage
   d'adresses IP (si approprié au type de connexion), un nom de base de données, un
   nom d'utilisateur et la méthode d'authentification à utiliser pour les
   connexions correspondant à ces paramètres. Le premier enregistrement
   qui correspond au type de connexion, à l'adresse client, à la base de données
   demandée et au nom d'utilisateur est utilisé pour effectuer l'authentification.
   Il n'y a pas de suite après une erreur (<quote>fall-through</quote> ou
   <quote>backup</quote>)&nbsp;: si un enregistrement est choisi et que l'authentification
   échoue, les enregistrements suivants ne sont pas considérés. Si aucun
   enregistrement ne correspond, l'accès est refusé.</para>

  <para>Un enregistrement peut avoir l'un des sept formats suivants.
<synopsis>local      <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>auth-method</replaceable>  <optional><replaceable>auth-option</replaceable></optional>
host       <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>CIDR-address</replaceable>  <replaceable>auth-method</replaceable>  <optional><replaceable>auth-option</replaceable></optional>
hostssl    <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>CIDR-address</replaceable>  <replaceable>auth-method</replaceable>  <optional><replaceable>auth-option</replaceable></optional>
hostnossl  <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>CIDR-address</replaceable>  <replaceable>auth-method</replaceable>  <optional><replaceable>auth-option</replaceable></optional>
host       <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>IP-address</replaceable>  <replaceable>IP-mask</replaceable>  <replaceable>auth-method</replaceable>  <optional><replaceable>auth-option</replaceable></optional>
hostssl    <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>IP-address</replaceable>  <replaceable>IP-mask</replaceable>  <replaceable>auth-method</replaceable>  <optional><replaceable>auth-option</replaceable></optional>
hostnossl  <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>IP-address</replaceable>  <replaceable>IP-mask</replaceable>  <replaceable>auth-method</replaceable>  <optional><replaceable>auth-option</replaceable></optional></synopsis>


   La signification des champs est la suivante&nbsp;: 

   <variablelist>
    <varlistentry> <term><literal>local</literal></term>
     <listitem><para>Cet enregistrement intercepte les tentatives de connexion
     qui utilise les sockets du domaine Unix. Sans enregistrement de ce type, les
     connexions de sockets du domaine Unix ne sont pas autorisées.</para>
     </listitem></varlistentry>

    <varlistentry>
     <term><literal>host</literal></term>
     <listitem>
      <para>
       Cet enregistrement intercepte les tentatives de connexion par TCP/IP.
       Les lignes <literal>host</literal> s'appliquent à toute tentative de
       connexion, <acronym>SSL</acronym> ou non.
      </para>

      <note>
       <para>
        Les connexions TCP/IP ne sont pas autorisées si le serveur
        n'est pas démarré avec la valeur appropriée du paramètre de configuration
        <xref linkend="guc-listen-addresses"/>. En effet, par défaut, le
        serveur n'écoute que les connexions TCP/IP en provenance de
        l'adresse <literal>loopback</literal> locale, <literal>localhost</literal>.
       </para>
      </note>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>hostssl</literal></term>
     <listitem>
      <para>
       Cet enregistrement intercepte les seules tentatives de connexions par TCP/IP
       qui utilisent le chiffrement <acronym>SSL</acronym>.
      </para>

      <para>
       Pour utiliser cette fonction, le serveur
       doit être compilé avec le support de <acronym>SSL</acronym>. De plus,
       <acronym>SSL</acronym> doit être activé au démarrage du serveur en
       positionnant le paramètre de configuration <xref linkend="guc-ssl"/>
       (voir la <xref linkend="ssl-tcp"/> pour plus d'informations).
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>hostnossl</literal></term>
     <listitem>
      <para>
       Cet enregistrement a une logique opposée à <literal>hostssl</literal>&nbsp;: il
       n'intercepte que les tentatives de connexion qui n'utilisent pas
       <acronym>SSL</acronym>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>database</replaceable></term>
     <listitem>
      <para>
       Indique les noms des bases de données concernées par l'enregistrement. La 
       valeur <literal>all</literal> indique qu'il concerne toutes les bases
       de données.
       Le terme <literal>sameuser</literal> indique que l'enregistrement
       coïncide si la base de données demandée a le même nom que l'utilisateur
       demandé.
       Le terme <literal>samerole</literal> indique que l'utilisateur demandé doit
       être membre du rôle portant le même nom que la base de données demandée
       (<literal>samegroup</literal> est obsolète bien qu'il soit toujours accepté
       comme écriture alternative de <literal>samerole</literal>.). Dans
       tous les autres cas,
       c'est le nom d'une base de données particulière. Plusieurs noms de base de
       données peuvent être fournis en les séparant par des virgules. Un fichier contenant
       des noms de base de données peut être indiqué en faisant précéder le
       nom du fichier de <literal>@</literal>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>user</replaceable></term>
     <listitem>
      <para>
       Indique les utilisateurs de bases de données auxquels cet enregistrement
       correspond. La valeur <literal>all</literal> indique qu'il concerne tous
       les utilisateurs. Dans le cas contraire, il s'agit soit du nom d'un utilisateur
       spécifique de bases de données ou d'un nom de groupe précédé par un
       <literal>+</literal> (il n'existe pas de véritable distinction
       entre les utilisateurs et les groupes dans
       <productname>PostgreSQL</productname>&nbsp;; un <literal>+</literal>
       signifie exactement
       <quote>établit une correspondance pour tous les rôles faisant parti
       directement ou indirectement de ce rôle</quote> alors qu'un nom sans
       <literal>+</literal> établit une correspondance avec ce rôle spécifique).
       Plusieurs noms d'utilisateurs peuvent être fournis en les séparant
       par des virgules. Un fichier contenant des noms d'utilisateurs peut
       être indiqué en faisant précéder le nom du fichier de <literal>@</literal>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>CIDR-address</replaceable></term>
     <listitem>
      <para>
      Indique la plage d'adresses IP client à laquelle correspond cet
      enregistrement. Il contient une adresse IP dans la notation décimale
      standard et une longueur de masque CIDR (les adresses IP
      ne peuvent qu'être indiquées numériquement, pas en tant que
      nom d'hôte ou de domaine). La longueur du masque indique le nombre de
      bits forts pour lesquels une correspondance doit être trouvée avec l'adresse
      IP du client. Les bits de droite doivent valoir zéro dans l'adresse IP
      indiquée. Il ne doit y avoir aucune espace entre l'adresse IP, le
      <literal>/</literal> et la longueur du masque CIDR.
      </para>

      <para>
      Une adresse CIDR (<replaceable>CIDR-address</replaceable>) est typiquement
      <literal>172.20.143.89/32</literal> pour un hôte seul,
      <literal>172.20.143.0/24</literal> pour un petit réseau ou
      <literal>10.6.0.0/16</literal> pour un réseau plus grand. Pour
      n'indiquer qu'un seul hôte, on utilise un masque de 32 pour IPv4 ou 128 pour
      IPv6. Dans une adresse réseau, ne pas oublier les zéros finaux.
      </para>

      <para>
       Une adresse IP indiquée au format IPv4 coïncide avec les connexions IPv6 
       d'adresse correspondante. Par exemple, <literal>127.0.0.1</literal> correspond
       à l'adresse IPv6 <literal>::ffff:127.0.0.1</literal>. Une entrée donnée au
       format IPv6 correspond uniquement aux connexions IPv6 même si l'adresse
       représentée est dans le domaine IPv4-vers-IPv6. Les adresses au
       format IPv6 sont rejetées si la bibliothèque système C ne supporte pas
       les adresses IPv6.
      </para>

      <para>Ce champ ne concerne que les enregistrements
       <literal>host</literal>, <literal>hostssl</literal> et
       <literal>hostnossl</literal>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>IP-address</replaceable></term>
     <term><replaceable>IP-mask</replaceable></term>
     <listitem>
      <para>
       Ces champs peuvent être utilisés comme alternative à la notation
       <replaceable>CIDR-address</replaceable>. Au lieu de spécifier la longueur
       du masque, le masque réel est indiquée dans une colonne distincte. Par
       exemple, <literal>255.0.0.0</literal> représente une longueur de masque CIDR
       IPv4 de 8, et <literal>255.255.255.255</literal> représente une longueur de
       masque de 32.
      </para>

      <para>Ces champ ne concernent que les enregistrements 
      <literal>host</literal>, <literal>hostssl</literal> et
      <literal>hostnossl</literal>.
    </para> 
    </listitem> 
    </varlistentry>  

    <varlistentry> <term><replaceable>auth-method</replaceable></term>
    <listitem> 
     <para>
      Indique la méthode d'authentification à utiliser lors d'une
      connexion via cet enregistrement. Les choix possibles sont résumés ici&nbsp;; les
      détails se trouvent dans la <xref linkend="auth-methods"/>.

       <variablelist>
        <varlistentry>
         <term><literal>trust</literal></term>
          <listitem>
           <para>
            Autorise la connexion sans condition. Cette méthode permet à
            quiconque peut se connecter au serveur de bases de données
            de s'enregistrer sous n'importe quel utilisateur
            <productname>PostgreSQL</productname> de son choix sans 
            mot de passe. Voir la <xref linkend="auth-trust"/> pour les détails.
           </para>
          </listitem>
         </varlistentry>

       <varlistentry>
        <term><literal>reject</literal></term>
         <listitem>
          <para>
           Rejette la connexion sans condition. Ce cas est utile
           pour <quote>filtrer</quote> certains hôtes d'un groupe.
          </para>
         </listitem>
        </varlistentry>

       <varlistentry>
       <term><literal>md5</literal></term>
       <listitem>
       <para>
       Demande au client de fournir un mot de passe chiffré MD5 pour
       l'authentification. Voir la <xref linkend="auth-password"/> pour
       les détails.
       </para>
       </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>crypt</literal></term>
        <listitem>
         <note>
         <para>
          Cette option est uniquement recommandée pour communiquer avec
          les clients de version antérieure à la 7.2.
         </para>
         </note>
         <para>
          Requiert que le client fournisse un mot de passe chiffré avec
          <function>crypt()</function> pour l'authentification. <literal>md5</literal>
          est maintenant recommandé à la place de <literal>crypt</literal>. Voir
          la <xref linkend="auth-password"/> pour les détails.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>password</literal></term>
        <listitem>
         <para>
          Requiert que le client fournisse un mot de passe non chiffré pour
          l'authentification. Comme le mot de passe est envoyé en clair sur
          le réseau, ceci ne doit pas être utilisé sur des réseaux non
          dignes de confiance. De plus, cette option ne fonctionne pas avec
          les applications client qui utilisent les threads. Voir la
          <xref linkend="auth-password"/> pour les détails.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>gss</literal></term>
        <listitem>
         <para>
          Utilise GSSAPI pour authentifier l'utilisateur. Disponible uniquement
          pour les connexions TCP/IP. Voir <xref
          linkend="gssapi-auth"/> pour les détails.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>sspi</literal></term>
        <listitem>
         <para>
          Utilise SSPI pour authentifier l'utilisateur. Disponible uniquement
          sur Windows. Voir <xref
          linkend="sspi-auth"/> pour plus de détails.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>krb5</literal></term>
        <listitem>
         <para>
          Utilise Kerberos V5 pour authentifier l'utilisateur. Ceci n'est
          disponible que pour les connexions TCP/IP. Voir la
          <xref linkend="kerberos-auth"/> pour les détails.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>ident</literal></term>
        <listitem>
         <para>
          Récupère le nom de l'utilisateur du système d'exploitation du client
          (pour les connexions TCP/IP en contactant le serveur d'identification
          sur le client, pour les connexions locales en l'obtenant du système
          d'exploitation) et vérifie si l'utilisateur est autorisé à se
          connecter avec l'utilisateur de base de données indiqué en
          consultant la correspondance indiquée après le mot clé
          <literal>ident</literal>. Voir la <xref linkend="auth-ident"/>
          ci-dessous pour les détails.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>ldap</literal></term>
        <listitem>
         <para>
          Authentification par LDAP sur serveur central. Voir la
          <xref linkend="auth-ldap"/> pour les détails.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>pam</literal></term>
        <listitem>
         <para>
          Authentification par les Pluggable Authentification Modules (PAM)
          fournis par le système d'exploitation. Voir la <xref linkend="auth-pam"/>
          pour les détails.
         </para>
        </listitem>
       </varlistentry>
      </variablelist>
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable>auth-option</replaceable></term>
     <listitem>
      <para>
       La signification de ce champ optionnel dépend de la méthode
       d'authentification choisie. Les détails sont disponibles ci-dessous.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   Les fichiers inclus par les constructions <literal>@</literal> sont lus comme des
   listes de noms, séparés soit par des espaces soit par
   des virgules. Les commentaires sont introduits par le caractère
   <literal>#</literal> comme dans <filename>pg_hba.conf</filename>, et les
   constructions <literal>@</literal> imbriquées sont autorisées. À moins
   que le nom du fichier qui suit <literal>@</literal> ne soit un chemin absolu,
   il est supposé relatif au répertoire contenant le fichier le référençant.
  </para>

  <para>
   Les enregistrements du fichier <filename>pg_hba.conf</filename> sont
   examinés séquentiellement à chaque tentative de connexion, l'ordre des
   enregistrements est donc significatif. Généralement, les premiers enregistrements
   ont des paramètres d'interception de connexions stricts et des méthodes
   d'authentification peu restrictives tandis que les
   enregistrements suivants ont des paramètres plus larges et des méthodes
   d'authentification plus fortes. Par exemple, on peut souhaiter utiliser
   l'authentification <literal>trust</literal> pour les connexions TCP/IP locales mais
   demander un mot de passe pour les connexion TCP/IP distantes. Dans ce cas, 
   l'enregistrement précisant une authentification <literal>trust</literal> pour les
   connexions issues de 127.0.0.1 apparaît avant un enregistrement indiquant
   une authentification par mot de passe pour une plage plus étendue d'adresses IP
   client autorisées.
  </para>

  <para>
   Le fichier <filename>pg_hba.conf</filename> est lu au démarrage et
   lorsque le processus serveur principal reçoit un signal
   <systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>.
   Si le fichier est édité sur un système actif, on peut signaler au
   serveur (en utilisant <literal>pg_ctl reload</literal> ou 
   <literal>kill -HUP</literal>) de relire le fichier.
  </para>

  <tip>
   <para>
    Pour se connecter à une base particulière, un utilisateur doit non
    seulement passer les vérifications de <filename>pg_hba.conf</filename> mais doit
    également avoir le droit <literal>CONNECT</literal> sur cette base. Pour
    contrôler qui peut se connecter à quelles bases, il est en général plus
    facile de le faire en donnant ou retirant le privilège 
    <literal>CONNECT</literal> plutôt qu'en
    plaçant des règles dans le fichier <filename>pg_hba.conf</filename>.
   </para>
  </tip>

  <para>
   Quelques exemples d'entrées de <filename>pg_hba.conf</filename> sont
   donnés ci-dessous dans l'<xref linkend="example-pg-hba.conf"/>. Voir la
   section suivante pour les détails des méthodes d'authentification.  </para>

   <example id="example-pg-hba.conf">
   <title>Exemple d'entrées de <filename>pg_hba.conf</filename></title>
<programlisting># Permettre à n'importe quel utilisateur du système local de se connecter
# à la base de données sous n'importe quel nom d'utilisateur au travers
# des sockets de domaine Unix (par défaut pour les connexions locales).
#
# TYPE  DATABASE    USER        CIDR-ADDRESS        METHOD
local   all         all                             trust

# La même chose en utilisant les connexions TCP/IP locales loopback.
#
# TYPE  DATABASE    USER        CIDR-ADDRESS        METHOD
host    all         all         127.0.0.1/32        trust

# Pareil mais en utilisant une colonne netmask distincte.
#
# TYPE  DATABASE    USER        IP-ADDRESS          IP-mask              METHOD
host    all         all         127.0.0.1           255.255.255.255      trust

# Permettre à n'importe quel utilisateur de n'importe quel hôte d'adresse IP
# 192.168.93.x de se connecter à la base de données "postgres" sous le nom
# d'utilisateur qu'ident signale à la connexion (généralement le
# nom utilisateur Unix).
# 
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
host    postgres    all         192.168.93.0/24       ident sameuser

# Permet à un utilisateur de l'hôte 192.168.12.10 de se connecter à la base de
# données "postgres" si le mot de passe de l'utilisateur est correctement fourni.
# 
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
host    postgres    all         192.168.12.10/32      md5

# Si aucune ligne "host" ne précède, ces deux lignes rejettent toutes
# les connexions en provenance de 192.168.54.1 (puisque cette entrée déclenche
# en premier), mais autorisent les connexions Kerberos 5 de n'importe où
# ailleurs sur l'Internet. Le masque zéro signifie qu'aucun bit de l'ip de
# l'hôte n'est considéré, de sorte à correspondre à tous les hôtes.
# 
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
host    all         all         192.168.54.1/32       reject
host    all         all         0.0.0.0/0             krb5

# Permettre à tous les utilisateurs de se connecter depuis 192.168.x.x à n'importe
# quelle base de données s'ils passent la verification d'identification. Si,
# par exemple, ident indique que l'utilisateur est "bryanh" et qu'il
# demande à se connecter en tant qu'utilisateur PostgreSQL "guest1", la
# connexion n'est permise que s'il existe une entrée dans pg_ident.conf pour la
# correspondance "omicron" disant que "bryanh" est autorisé à se connecter en
# tant que "guest1".
#
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
host    all         all         192.168.0.0/16        ident omicron

# Si ces trois lignes traitent seules les connexions locales, elles
# n'autorisent les utilisateurs locaux qu'à se connecter à leur propre
# base de données (base ayant le même nom que leur nom
# d'utilisateur) exception faite des administrateurs
# et des membres du rôle "support" qui peuvent se connecter à toutes les bases
# de données. Le fichier $PGDATA/admins contient une liste de noms
# d'administrateurs. Un mot de passe est requis dans tous les cas.
#
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   sameuser    all                               md5
local   all         @admins                           md5
local   all         +support                          md5

# Les deux dernières lignes ci-dessus peuvent être combinées en une seule ligne :
local   all         @admins,+support                  md5

# La colonne database peut aussi utiliser des listes et des noms de fichiers :
local   db1,db2,@demodbs  all                         md5</programlisting> </example> </sect1>

 <sect1 id="auth-methods">
 <title>Méthodes d'authentification</title>
 <para>
  Les sous-sections suivantes décrivent les méthodes d'authentification en détail.
 </para>

  <sect2 id="auth-trust">
  <title>Authentification trust</title>

   <para>
    Quand l'authentification <literal>trust</literal> est utilisée,
    <productname>PostgreSQL</productname> considère que quiconque peut se
    connecter au serveur est autorisé à accéder à la base de données quel que
    soit le nom d'utilisateur de bases de données qu'il fournit (ce qui
    inclut les super-utilisateurs). Les restrictions apportées dans les
    colonnes <literal>database</literal> et <literal>user</literal>
    continuent évidemment de s'appliquer. Cette méthode ne doit être utilisée
    que si le système assure un contrôle adéquat des connexions au serveur.
   </para>

   <para>
    L'authentification <literal>trust</literal> est appropriée et très pratique
    pour les connexions locales sur une station de travail mono-utilisateur. Elle
    n'est généralement <emphasis>pas</emphasis> appropriée en soi sur une machine
    multi-utilisateur. Cependant, <literal>trust</literal> peut tout de même 
    être utilisé sur une machine multi-utilisateur, si l'accès au fichier
    socket de domaine Unix est restreint par les permissions du système de
    fichiers. Pour ce faire, on peut positionner les paramètres de configuration
    <varname>unix_socket_permissions</varname> (et au besoin
    <varname>unix_socket_group</varname>) comme cela est décrit dans la
    <xref linkend="runtime-config-connection"/>. 
    On peut également positionner le paramètre de configuration
    <varname>unix_socket_directory</varname> pour placer le fichier de socket
    dans un répertoire à l'accès convenablement restreint.
   </para>

   <para>
    Le réglage des droits du système de fichiers n'a d'intérêt que le cas de
    connexions par les sockets Unix. Cela ne restreint pas les connexions
    TCP/IP locales&nbsp;; ainsi, pour utiliser les droits du système de
    fichiers pour assurer la sécurité locale, il faut supprimer la ligne
    <literal>host ...127.0.0.1 ...</literal> de
    <filename>pg_hba.conf</filename> ou la modifier pour utiliser une méthode
    d'authentification différente de <literal>trust</literal>.
   </para>

   <para>
    L'authentification <literal>trust</literal> n'est envisageable, pour les
    connexions TCP/IP, que si chaque utilisateur de chaque machine autorisée
    à se connecter au serveur par les lignes <literal>trust</literal> du
    fichier <filename>pg_hba.conf</filename> est digne de confiance. Il est
    rarement raisonnable d'utiliser <literal>trust</literal> pour les
    connexions autres que celles issues de
    <systemitem>localhost</systemitem> (127.0.0.1).
   </para>

  </sect2>

  <sect2 id="auth-password"> <title>Authentification par mot de passe</title>

   <indexterm>
    <primary>MD5</primary>
   </indexterm>

   <indexterm>
     <primary>crypt</primary>
   </indexterm>
   <indexterm>
     <primary>password</primary>
     <secondary>authentification</secondary>
   </indexterm>
   <indexterm>
    <primary>mot de passe</primary>
    <secondary>authentification</secondary>
   </indexterm>

   <para>
    Les méthodes fondées sur une authentification par mot de passe sont
    <literal>md5</literal>, <literal>crypt</literal> et
    <literal>password</literal>. Ces méthodes
    fonctionnent de façon analogue à l'exception du mode d'envoi du mot de passe
    à travers la connexion&nbsp;: respectivement, hachage MD5, chiffrement via
    crypt et texte en clair. Une limitation de la méthode <literal>crypt</literal> est
    qu'elle ne fonctionne pas avec les mots de passe chiffrés dans
    <structname>pg_authid</structname>.
   </para>

   <para>
    S'il existe un risque d'attaque par <quote>interception (sniffing)</quote>
    des mots de passe, il est préférable d'utiliser <literal>md5</literal>,
    <literal>crypt</literal> devant être limité aux client pré-7.2.
    L'utilisation de <literal>password</literal>, en clair, est tout
    particulièrement à éviter lors de connexions ouvertes sur l'Internet
    (à moins d'utiliser <acronym>SSL</acronym>, <acronym>SSH</acronym> ou
    tout autre système de sécurisation par encapsulation de la connexion).
   </para>

   <para>
    Les mots de passe <productname>PostgreSQL</productname>
    sont distincts des mots de passe du système d'exploitation. Le mot de passe
    de chaque utilisateur est enregistré dans le catalogue système
    <literal>pg_authid</literal>. Ils peuvent être gérés avec les
    commandes SQL <xref linkend="sql-createuser" endterm="sql-createuser-title"/>
    et <xref linkend="sql-alteruser" endterm="sql-alteruser-title"/>. Ainsi, par
    exemple, <userinput>CREATE USER foo WITH PASSWORD 'secret';</userinput>. Par
    défaut, c'est à dire si aucun mot de passe n'est indiqué, le mot de passe enregistré
    est nul et l'authentification par mot de passe échoue systématiquement pour
    cet utilisateur.
   </para>

  </sect2>

  <sect2 id="gssapi-auth">
   <title>Authentification GSSAPI</title>

   <indexterm zone="gssapi-auth">
    <primary>GSSAPI</primary>
   </indexterm>

   <para>
    <productname>GSSAPI</productname> est un protocole du standard de
    l'industrie pour l'authentification sécurisée définie dans RFC 2743.
    <productname>PostgreSQL</productname> supporte
    <productname>GSSAPI</productname> avec l'authentification
    <productname>Kerberos</productname> suivant la RFC 1964.
    <productname>GSSAPI</productname> fournit une authentification
    automatique (<foreignphrase>single sign-on</foreignphrase>) pour les
    systèmes qui le supportent. L'authentification elle-même est sécurisée
    mais les données envoyées sur la connexion seront en clair sauf si
    <acronym>SSL</acronym> est utilisé.
   </para>

   <para>
    Quand <productname>GSSAPI</productname> passe par
    <productname>Kerberos</productname>, il utilise un principal standard
    dans le format
        <literal><replaceable>nomservice</replaceable>/<replaceable>nomhôte</replaceable>@<replaceable>domaine</replaceable></literal>.
    Pour des informations sur les parties du principal et sur la façon de
    configurer les clés requises, voir <xref linkend="kerberos-auth"/>. Le
    support de GSSAPI doit être activé lors de la construction de
    <productname>PostgreSQL</productname>&nbsp;; voir
    <xref linkend="installation"/> pour plus d'informations.
   </para>
   
  </sect2>

  <sect2 id="sspi-auth">
   <title>Authentification SSPI</title>

   <indexterm zone="sspi-auth">
    <primary>SSPI</primary>
   </indexterm>

   <para>
    <productname>SSPI</productname> est une technologie
    <productname>Windows</productname> pour l'authentification sécurisée avec
    <foreignphrase>single sign-on</foreignphrase>.
    <productname>PostgreSQL</productname> utilise SSPI dans un mode de
    négociation (<literal>negotiate</literal>) qui utilise
    <productname>Kerberos</productname> si possible et
    <productname>NTLM</productname> sinon. L'authentification
    <productname>SSPI</productname> ne fonctionne que loresque serveur et
    client utilisent <productname>Windows</productname>.
   </para>

   <para>
    Lorsque <productname>Kerberos</productname> est utilisé,
    <productname>SSPI</productname> fonctionne de la même façon que
    <productname>GSSAPI</productname>.
    Voir <xref linkend="gssapi-auth"/> pour les détails.
   </para>

  </sect2>

  <sect2 id="kerberos-auth"> <title>Authentification Kerberos</title>

   <indexterm zone="kerberos-auth"> <primary>Kerberos</primary> </indexterm>

   <note>
    <para>
     L'authentification Kerberos native est obsolète et ne doit être
     utilisée que pour assurer la compatibilité ascendante. 
     Les nouvelles installations et les mises à jour utiliseront
     préférentiellement le standard d'authentification
     de l'industrie, <productname>GSSAPI</productname> (voir <xref
     linkend="gssapi-auth"/>).
    </para>
   </note>

   <para>
    <productname>Kerberos</productname> est un système d'authentification
    sécurisée de standard industriel destiné à l'informatique distribuée sur un
    réseau public. La description de <productname>Kerberos</productname>
    dépasse largement les objectifs de ce document&nbsp; même dans les
    généralités, c'est assez complexe (bien que puissant). La
    <ulink url="http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html">
    <acronym>FAQ</acronym> Kerberos</ulink> ou la
    <ulink url="http://web.mit.edu/kerberos/www/">page Kerberos du
    MIT</ulink> sont un bon point de départ à l'exploration. Il existe plusieurs
    sources de distribution <productname>Kerberos</productname>.
    <productname>Kerberos</productname> fournit une authentification sécurisée
    mais ne chiffre pas les requêtes ou les données passées sur le réseau&nbsp;;
    pour cela, <acronym>SSL</acronym> doit être utilisé.
   </para>

   <para>
    <productname>PostgreSQL</productname> supporte Kerberos version 5. Le
    support de Kerberos doit être activé lors de la construction de
    <productname>PostgreSQL</productname>&nbsp;; voir le
    <xref linkend="installation"/> pour plus d'informations.
   </para>

   <para>
    <productname>PostgreSQL</productname> opère comme un service Kerberos normal.
    Le nom du service principal est
    <literal><replaceable>nomservice</replaceable>/<replaceable>nomhôte</replaceable>@<replaceable>domaine</replaceable></literal>.
   </para>

   <para>
    <replaceable>nomservice</replaceable> peut être configuré du côté serveur en utilisant
    le paramètre de configuration <xref linkend="guc-krb-srvname"/> (voir
    aussi <xref linkend="libpq-connect"/>). La valeur par défaut à
    l'installation, <literal>postgres</literal>, peut être modifiée lors
    de la construction avec
    <literal>./configure --with-krb-srvnam=quelquechose</literal>. Dans la
    plupart des environnements, il est inutile de modifier cette valeur.
    Néanmoins, pour supporter
    plusieurs installations de <productname>PostgreSQL</productname> sur le même hôte,
    cela devient nécessaire. Quelques implantations de Kerberos peuvent
    imposer un nom de service différent, comme Microsoft Active
    Directory qui réclame un nom du service en majuscules
    (<literal>POSTGRES</literal>).
   </para>

   <para>
    <replaceable>nom_hote</replaceable> est le nom de l'hôte pleinement
    qualifié (<foreignphrase>fully qualified host name</foreignphrase>)
    de la machine serveur. Le domaine du service principal (client)
    est le domaine préféré du serveur.
   </para>

   <para>
    Les principaux (clients) doivent contenir le nom de leur utilisateur
    <productname>PostgreSQL</productname> comme premier composant,
    <literal>nomutilisateurpg@domaine</literal>, par exemple.
    Par défaut, le domaine du client n'est pas vérifié par
    <productname>PostgreSQL</productname>. Si l'authentification inter-domaine
    (<foreignphrase>cross-realm</foreignphrase>) est activée, on utilise le
    paramètre <xref linkend="guc-krb-realm"/>.
   </para>

   <para>
    Le fichier de clés du serveur doit être lisible (et de préférence
    uniquement lisible) par le compte serveur
    <productname>PostgreSQL</productname> (voir aussi la
    <xref linkend="postgres-user"/>). L'emplacement du fichier de clés est
    indiqué grâce au paramètre de configuration
    <xref linkend="guc-krb-server-keyfile"/> fourni à l'exécution. La valeur
    par défaut est <filename>/etc/srvtab</filename>, si Kerberos 4 est
    utilisé, et <filename>/usr/local/pgsql/etc/krb5.keytab</filename> sinon
    (ou tout autre répertoire indiqué comme <varname>sysconfdir</varname> à
    la compilation).
   </para>

   <para>
    Le fichier de clés est engendré par le logiciel Kerberos&nbsp;; voir la
    documentation de Kerberos pour les détails. L'exemple suivant correspond
    à des implantations de Kerberos 5 compatibles avec MIT&nbsp;:
<screen><prompt>kadmin% </prompt><userinput>ank -randkey postgres/server.my.domain.org</userinput>
<prompt>kadmin% </prompt><userinput>ktadd -k krb5.keytab postgres/server.my.domain.org</userinput></screen>
   </para>

   <para>
    Lors de la connexion à la base de données, il faut s'assurer de posséder
    un ticket pour le principal correspondant au nom d'utilisateur de base
    de données souhaité. Par exemple, pour le nom d'utilisateur
    <literal>fred</literal>, les deux
    principaux <literal>fred@EXAMPLE.COM</literal>
    et <literal>fred/users.exemple.com@EXAMPLE.COM</literal> peuvent être utilisés
    pour authentifier le serveur de bases de données.
   </para>

   <para>
    Si <ulink url="http://modauthkerb.sf.net">mod_auth_kerb</ulink> et
    <application>mod_perl</application> sont utilisés sur le serveur web
    <productname>Apache</productname>, 
    <literal>AuthType KerberosV5SaveCredentials</literal> peut être utilisé
    avec un script <application>mod_perl</application>. Cela fournit un accès
    sûr aux bases de données, sans demander de mot de passe supplémentaire.
   </para>

  </sect2>

  <sect2 id="auth-ident"> <title>Authentification fondée sur ident</title>

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

   <para>
    La méthode d'authentification par ident fonctionne en obtenant les noms
    des utilisateurs du système d'exploitation, puis en déterminant les noms
    des utilisateurs de bases de données autorisés à l'aide d'un fichier
    de correspondance qui liste les paires autorisées de concordance de
    noms. La résolution du nom d'utilisateur du client est le point de sécurité
    critique. Elle fonctionne différemment selon le type de connexion.
   </para>

   <sect3> <title>Authentification par ident en TCP/IP</title>

   <para>
    Le <quote>protocole d'identification</quote> est décrit dans la
    RFC 1413. Théoriquement, chaque système
    d'exploitation de type Unix contient un serveur ident
    qui écoute par défaut sur le port TCP 113. La fonctionnalité basique
    d'un serveur ident est de répondre aux questions telles que&nbsp;:
    <quote>Quel utilisateur a initié la connexion qui sort du port
    <replaceable>X</replaceable> et se connecte à mon port
    <replaceable>Y</replaceable>?</quote>.
    Puisque <productname>PostgreSQL</productname> connaît
    <replaceable>X</replaceable> et <replaceable>Y</replaceable> dès lors
    qu'une connexion physique est établie, il peut interroger le serveur
    ident de l'hôte du client qui se connecte et peut ainsi théoriquement
    déterminer l'utilisateur du système d'exploitation pour n'importe quelle
    connexion.
   </para>

   <para>
    Le revers de cette procédure est qu'elle dépend de l'intégrité du
    client&nbsp;: si la machine cliente est douteuse ou compromise, un attaquant
    peut lancer n'importe quel programme sur le port 113 et retourner un nom
    d'utilisateur de son choix. Cette méthode d'authentification n'est, par
    conséquent, appropriée que dans le cas de réseaux fermés dans lesquels
    chaque machine cliente est soumise à un contrôle strict et dans lesquels
    les administrateurs système et de bases de données opèrent en étroite
    collaboration. En d'autres mots, il faut pouvoir faire confiance à la
    machine hébergeant le serveur d'identification. Cet avertissement doit
    être gardé à l'esprit&nbsp;:
    <blockquote>
     <attribution>RFC 1413</attribution>
     <para>
      Le protocole d'identification n'a pas vocation à être un protocole
      d'autorisation ou de contrôle d'accès.
     </para>
    </blockquote>
   </para>

   <para>
    Certains serveurs ident ont une option non standard qui chiffre le nom de
    l'utilisateur retourné à l'aide d'une clé connue du seul administrateur
    de la machine dont émane la connexion. Cette option <emphasis>ne
    doit pas</emphasis> être employée lorsque le serveur ident est utilisé avec
    <productname>PostgreSQL</productname> car <productname>PostgreSQL</productname>
    n'a aucun moyen de déchiffré la chaîne renvoyée pour déterminer le nom réel
    de l'utilisateur.
   </para>

</sect3>

   <sect3> <title>Authentification par ident sur sockets locaux</title>

   <para>
    Sur les systèmes qui supportent les requêtes <symbol>SO_PEERCRED</symbol>
    pour les sockets de domaine Unix (actuellement
    <systemitem class="osname">Linux</systemitem>,
    <systemitem class="osname">FreeBSD</systemitem>,
    <systemitem class="osname">NetBSD</systemitem>,
    <systemitem class="osname">OpenBSD</systemitem> et
    <systemitem class="osname">BSD/OS</systemitem>), l'authentification par
    ident peut aussi être appliquée aux connexions locales. Dans ce cas,
    l'utilisation de l'authentification par ident n'ajoute aucun risque de
    sécurité&nbsp; en fait, c'est même un choix préférable sur ce genre de
    système.
   </para>

    <para>
     Sur les systèmes sans requête <symbol>SO_PEERCRED</symbol>, l'authentification
     par ident n'est disponible que pour les connexions TCP/IP. Pour pallier
     ceci, il est possible de préciser l'adresse
     <systemitem class="systemname">localhost</systemitem>
     <systemitem class="systemname">127.0.0.1</systemitem> et d'établir une
     connexion à cette adresse. Si le serveur ident local est digne de
     confiance, alors cette méthode l'est aussi.
    </para>
   </sect3>

   <sect3 id="auth-ident-maps">
    <title>Correspondances d'identité</title>

   <para>
    Lorsque l'authentification par ident est utilisée, après avoir déterminé
    le nom de l'utilisateur du système d'exploitation qui a initié la
    connexion, <productname>PostgreSQL</productname> vérifie si cet utilisateur
    est autorisé à se connecter avec le nom d'utilisateur de bases de données
    souhaité. Ceci est contrôlé par l'argument ident map qui suit le mot clé
    <literal>ident</literal> dans le fichier <filename>pg_hba.conf</filename>.
    Il existe une correspondance d'identité prédéfinie,
    <literal>sameuser</literal>, qui permet à n'importe quel utilisateur du
    système d'exploitation de se connecter en tant qu'utilisateur de même nom
    au serveur de bases de données (si ce dernier existe). Les autres correspondances
    doivent être créées manuellement.
   </para> 

   <para>
    Les correspondances d'identité autres que <literal>sameuser</literal>
    sont définies dans le fichier de concordance, par défaut nommé
    <filename>pg_ident.conf</filename>
    <indexterm><primary>pg_ident.conf</primary></indexterm> et stocké
    dans le répertoire data (il est possible de placer ce fichier
    ailleurs&nbsp;; voir le paramètre de configuration
    <xref linkend="guc-ident-file"/>). Ce fichier contient des lignes de
    la forme&nbsp;:
<synopsis><replaceable>nom-correspondance</replaceable> <replaceable>nomutilisateur-ident</replaceable> <replaceable>base-donnee-utilisateur</replaceable></synopsis>
    Les commentaires et les espaces sont gérés comme dans le
    fichier <filename>pg_hba.conf</filename>. Le
    <replaceable>nom-correspondance</replaceable> est un
    nom arbitraire utilisé pour se référer à cette correspondance dans
    <filename>pg_hba.conf</filename>. Les deux autres champs indiquent le
    nom de l'utilisateur du système d'exploitation et le nom de
    l'utilisateur de base avec lequel il
    est autorisé à se connecter. Le même <replaceable>nom-correspondance</replaceable>
    peut être répété pour indiquer plusieurs correspondances d'utilisateur au sein
    d'une même table de correspondance. Il n'y a pas de restriction sur le nombre
    d'utilisateurs de bases de données auxquels un utilisateur de système
    d'exploitation donné peut correspondre et vice-versa.
   </para>

   <para>
    Le fichier <filename>pg_ident.conf</filename> est lu au démarrage et
    à chaque fois que le processus serveur principal reçoit un signal
    <systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>.<