root/traduc/branches/bv803/manuel/client-auth.sgml

<!--
$Header: /var/lib/cvs/pgsql-fr/sgml/client-auth.sgml,v 1.10 2005/07/15 06:14:20 guillaume Exp $
-->

<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 base de données,
  elle indique le nom de l'utilisateur <productname>PostgreSQL</productname> sous
  lequel elle désire se connecter, comme lorsqu'on se connecte sur 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 des bases de données auxquelles les utilisateurs peuvent se
  connecter.</para>

 <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, par
  lequel il détermine si l'application cliente (ou l'utilisateur sous le nom de
  laquelle elle tourne) est autorisée à se connecter sous le nom d'utilisateur
  demandé.</para>

 <para><productname>PostgreSQL</productname> offre quantité de méthodes
  d'authentification différentes. La méthode d'authentification d'une connection
  client particulière peut être sélectionnée d'après l'adresse, la base de données
  et l'utilisateur de l'hôte client.</para>

 <para>Les noms d'utilisateurs <productname>PostgreSQL</productname> sont
  séparés de façon logique des noms d'utilisateurs 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 des noms
  d'utilisateurs de la base de données qui correspondent aux noms d'utilisateurs
  du système d'exploitation.  Cependant, un serveur qui accepte les connexions
  distantes peut avoir plusieurs utilisateurs de base de données dépourvus de
  compte correspondant sur le système d'exploitation, dans de tels cas il n'y a
  pas besoin de correspondance entre noms d'utilisateurs de bases de données et
  noms d'utilisateurs du système d'exploitation.</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</>
   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 être  continué sur plusieurs lignes.</para>

  <para>Chaque enregistrement détermine 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
   correspondant 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 erreur (<quote>fall-through</> ou
   <quote>backup</>)&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 formats suivants.
<synopsis>
local      <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>authentication-method</replaceable>  <optional><replaceable>authentication-option</replaceable></optional>
host       <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>CIDR-address</replaceable>  <replaceable>authentication-method</replaceable>  <optional><replaceable>authentication-option</replaceable></optional>
hostssl    <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>CIDR-address</replaceable>  <replaceable>authentication-method</replaceable>  <optional><replaceable>authentication-option</replaceable></optional>
hostnossl  <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>CIDR-address</replaceable>  <replaceable>authentication-method</replaceable>  <optional><replaceable>authentication-option</replaceable></optional>
host       <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>IP-address</replaceable>  <replaceable>IP-mask</replaceable>  <replaceable>authentication-method</replaceable>  <optional><replaceable>authentication-option</replaceable></optional>
hostssl    <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>IP-address</replaceable>  <replaceable>IP-mask</replaceable>  <replaceable>authentication-method</replaceable>  <optional><replaceable>authentication-option</replaceable></optional>
hostnossl  <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>IP-address</replaceable>  <replaceable>IP-mask</replaceable>  <replaceable>authentication-method</replaceable>  <optional><replaceable>authentication-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
     utilisant les sockets du domaine Unix. Sans un enregistrement de ce type, les
     connections de sockets du domaine Unix ne sont pas permises.  </para>
     </listitem></varlistentry>

    <varlistentry>
     <term><literal>host</literal></term>
     <listitem>
      <para>
       Cet enregistrement intercepte les tentatives de connexion utilisant les
       réseaux TCP/IP. Les lignes <literal>host</literal> enregistrent des
       tentatives de connexion soit <acronym>SSL</acronym> soit non
       <acronym>SSL</acronym>.
      </para>

      <note>
       <para>
        Supprimer les connexions TCP/IP ne sera pas possible si le serveur
        est lancé avec la valeur appropriée pour le paramètre de configuration
        <xref linkend="guc-listen-addresses"> car le comportement par défaut
        est d'écouter les connexions TCP/IP provenant seulement de l'adresse
        local <literal>localhost</>.
       </para>
      </note>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>hostssl</literal></term>
     <listitem>
      <para>
       Cet enregistrement intercepte les tentatives de connexions utilisant TCP/IP
       mais seulement quand ces connexions utilisent le chiffrement <acronym>SSL</acronym>.
      </para>

      <para>
       Pour être en mesure de faire usage de cette fonction, le serveur
       doit être compilé avec le support de <acronym>SSL</acronym>. De plus,
       <acronym>SSL</acronym> doit être activé au lancement 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</>&nbsp;: il
       n'intercepte que les tentatives de connexion n'utilisant pas
       <acronym>SSL</acronym>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>database</replaceable></term>
     <listitem>
      <para>
       Indique quelles bases de données l'enregistrement concerne. La valeur
       <literal>all</literal> indique qu'il concerne toutes les bases de données.
       La valeur <literal>sameuser</> spécifie que l'enregistrement n'intercepte
       que si la base de données demandée a le même nom que l'utilisateur demandé.
       La valeur <literal>samegroup</> spécifie que l'utilisateur demandé doit être
       membre du groupe portant le même nom que la base de données demandée. Sinon,
       c'est le nom d'une base de données <productname>PostgreSQL</productname>
       particulière. Des noms de bases de données multiples peuvent être fournis en
       les séparant par des virgules. Un fichier contenant des noms de bases de
       données peut être indiqué en faisant précéder le nom de fichier de
       <literal>@</>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>user</replaceable></term>
     <listitem>
      <para>
       Indique à quels utilisateurs <productname>PostgreSQL</> cet enregistrement
       correspond. La valeur <literal>all</literal> indique qu'il concerne tous
       les utilisateurs. Autrement, c'est le nom d'un utilisateur
       <productname>PostgreSQL</productname> particulier. Plusieurs noms
       d'utilisateurs peuvent être fournis en les séparant avec des virgules.
       Les noms de groupes peuvent être spécifiés en précédant le nom de groupe
       du signe <literal>+</>. Un fichier contenant des noms d'utilisateurs peut
       être indiqué en faisant précéder le nom de fichier du signe <literal>@</>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>CIDR-address</replaceable></term>
     <listitem>
      <para>
      Spécifie l'échelle d'adresses IP du client auquel correspond cet
      enregistrement. Il contient une adresse IP dans la notation décimale
      standard et une longueur de masque CIDR (les adresses IP
      peuvent seulement être spécifiées numériquement, mais pas en tant que
      nom d'hôte ou de domaine). La longueur du masque indique le nombre de
      bits pour lequel une correspondance doit être apportée avec l'adresse
      IP du client. Les bits à droite doivent valoir zéro dans l'adresse IP
      indiquée. Il ne doit y avoir aucun espace blanc 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 ou
      <literal>172.20.143.0/24</literal> pour un réseau. Pour spécifier un seul
      hôte, utilisez un masque de 32 pour IPv4 ou 128 pour IPv6.
      </para>

      <para>
       Une adresse IP au format IPv4 correspondra aux connexions IPv6 qui auront
       l'adresse correspondante. Par exemple, <literal>127.0.0.1</> correspondra
       à l'adresse IPv6 <literal>::ffff:127.0.0.1</>. Une entrée donnée au
       format IPv6 correspondra uniquement aux connexions IPv6 même si l'adresse
       représentée est dans le domaine IPv4-vers-IPv6. Notez que les adresses au
       format IPv6 seront 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</>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>IP-address</replaceable></term>
     <term><replaceable>IP-mask</replaceable></term>
     <listitem>
      <para>
       Ces champs pourraient être utilisés comme alternative à la notation
       <replaceable>CIDR-address</replaceable>. Au lieu de spécifier la longueur
       du masque, le masque actuel est spécifié comme une colonne séparée. Par
       exemple, <literal>255.0.0.0</> représente une longueur de masque CIDR
       IPv4 de 8, et <literal>255.255.255.255</> 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</>.
</para> </listitem> </varlistentry>  

    <varlistentry> <term><replaceable>authentication-method</replaceable></term>
<listitem> <para>Détermine 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</></term> <listitem>
<para>Autorise la connexion sans conditions. Cette méthode permet à
n'importe qui de se connecter au serveur de bases de données
<productname>PostgreSQL</productname>, de s'enregistrer comme n'importe quel
utilisateur <productname>PostgreSQL</productname> de son choix sans nécessiter
de mot de passe. Voir la <xref linkend="auth-trust"> pour les détails.  </para>
</listitem> </varlistentry>

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

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

       <varlistentry>
        <term><literal>crypt</></term>
        <listitem>
         <para>
          Requiert que le client fournisse un mot de passe crypté avec
          <function>crypt()</> pour l'authentification. <literal>md5</literal>
          est préféré pour les clients 7.2 et suivants mais les versions
          antérieures ne supportent que <literal>crypt</literal>. Voir <xref
          linkend="auth-password"> pour les détails.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>password</></term>
        <listitem>
         <para>
          Requiert que le client fournisse un mot de passe non crypté pour
          l'authentification. <literal>md5</> est préféré sur les clients 7.2
          et ultérieures mais les versions antérieures ne supportent que
          <literal>crypt</literal>. Voir <xref linkend="auth-password"> pour
          les détails.
         </para>
        </listitem>
       </varlistentry>

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

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

       <varlistentry>
        <term><literal>ident</></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 en tant qu'utilisateur de la base de données demandé 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>pam</></term>
        <listitem>
         <para>
          Authentifie en utilisant 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>authentication-option</replaceable></term>
     <listitem>
      <para>
       La signification de ce champ optionnel dépend de la méthode
       d'authentification choisie. Des détails sont disponibles ci-dessous.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   Les fichiers inclus par les constructions <literal>@</> sont lus comme des
   listes de noms, qui peuvent être séparés par soit des espaces blancs soit
   des virgules. Les commentaires sont introduits par le caractère
   <literal>#</literal> comme dans <filename>pg_hba.conf</filename>, et les
   constructions <literal>@</> imbriquées sont autorisées. Sauf si le nom du
   fichier suivant <literal>@</> est 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 pour chaque tentative de connexion, l'ordre des
enregistrements est significatif. Généralement, les premiers enregistrements
auront des paramètres d'interception de connexions plus stricts alors que les
enregistrements suivants auront des paramètres plus larges et des méthodes
d'authentification plus fortes. Par exemple, on pourrait souhaiter utiliser
l'authentification <literal>trust</> pour les connexions TCP/IP locales mais
demander un mot de passe pour les connexion TCP/IP distantes. Dans ce cas, un
enregistrement spécifiant une authentification <literal>trust</> pour les
connexions issues de 127.0.0.1 apparaîtrait avant un enregistrement spécifiant
une authentifications 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
quand le processus serveur principal (<command>postmaster</>) reçoit un signal
<systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>.
Si vous éditez le fichier sur un système actif, vous aurez à signaler au
<command>postmaster</> (en utilisant <literal>pg_ctl reload</> ou <literal>kill
-HUP</>) de relire le fichier.  </para>

  <para>Quelques exemples des entrées de <filename>pg_hba.conf</filename> sont décrit
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>
# Permet à n'importe quel utilisateur du système local de se connecter à la base
# de données sous n'importe quel nom d'utilisateur en utilisant les sockets du
# domaine Unix. (par défaut pour les connexions locales)
#
# TYPE  DATABASE    USER        CIDR-ADDRESS        METHOD
local   all         all                             trust

# Identique à ci-dessus mais utilise les connexions TCP/IP locales loopback.
#
# TYPE  DATABASE    USER        CIDR-ADDRESS        METHOD
host    all         all         127.0.0.1/32        trust

# Identique à la dernière ligne mais en utilisant une colonne netmask séparée CDIR.
#
# TYPE  DATABASE    USER        IP-ADDRESS          IP-mask              METHOD
host    all         all         127.0.0.1           255.255.255.255      trust

# Permet à n'importe que utilisateur de n'importe quel hôte avec l'adresse IP
# 192.168.93.x de se connecter à la base de données "template1" sous le même nom
# d'utilisateur que l'identification le signale à la connexion (généralement le
# nom utilisateur Unix).
# 
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
host    template1   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 "template1" si le mot de passe de l'utilisateur est fourni sans
# erreur.
# 
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
host    template1   all         192.168.12.10/32      md5

# En l'absence de lignes "host" antérieures, ces deux lignes rejetteront toutes
# les connexions en provenance de 192.168.54.1 (puisque cette entrée déclenchera
# en premier), mais autorisera les connexions Kerberos 5 de n'importe où
# ailleurs sur l'Internet. Le masque zéro signifie qu'aucun bit sur 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

# Permet à tous les utilisateurs de se connecter depuis 192.168.x.x à n'importe
# quelle base de données si ils passent la verification d'identification. Si,
# par exemple, l'identification 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 ce sont les trois seules lignes traitant les connexions locales, elles
# autoriseront les utilisateurs locaux à se connecter uniquement à leur propre
# base de données (bases de données ayant le même nom que leur nom
# d'utilisateur) exception faite pour les administrateurs et les membres du
# groupe "support" qui peuvent se connecter à toutes les bases de données.  Le
# fichier $PGDATA/admins contient une liste de noms d'utilisateurs. 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
# mais pas de groupes:
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 plus en détail.  </para>

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

   <para>
    Quand l'authentification <literal>trust</> est spécifiée,
    <productname>PostgreSQL</productname> suppose que n'importe qui pouvant se
    connecter au serveur est autorisé à accéder à la base de données quel que
    soit le nom d'utilisateur de base de données qu'il fournisse (incluant le
    super-utilisateur de la base de données). Bien sûr, les restrictions
    apportées dans les colonnes <literal>database</> et <literal>user</>
    s'appliquent toujours. Cette méthode ne devrait être utilisée que s'il
    existe des protections au niveau système portant sur les connexions au
    serveur.
   </para>

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

   <para>Utiliser les droits du système de fichiers n'est utile que dans
le cas de connexions utilisant des sockets Unix. Cela ne restreint pas les
connexions TCP/IP locales&nbsp;; ainsi, si vous voulez utiliser les droits du
système de fichiers pour assurer la sécurité locale, supprimez la ligne
<literal>host ...127.0.0.1 ...</> de <filename>pg_hba.conf</> ou changez-la
- indiquer une méthode d'authentification différente de <literal>trust</>.
</para>

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

  </sect2>

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

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

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

   <para>
    Les méthodes basées sur une authentification par mot de passe sont
    <literal>md5</>, <literal>crypt</> et <literal>password</>. Ces méthodes
    fonctionnent de façon analogue, sauf pour le mode d'envoi du mot de passe
    au travers de la connexion. Néanmoins, <literal>crypt</> n'autorise pas
    le stockage des mots de passe cryptées dans <structname>pg_shadow</structname>.
   </para>

   <para>
    Si vous êtes préoccupé par les attaques par <quote>interception
    (sniffing)</> de mot de passe, alors <literal>md5</> est préférable, avec
    <literal>crypt</> en second choix si vous devez supporter les client pré
    7.2. Le simple <literal>password</> devrait particulièrement être
    évité pour les connexion sur l'Internet ouvert (à moins d'utiliser
    <acronym>SSL</acronym>, SSH ou d'autres systèmes de sécurité par
    encapsulation de connexion).
   </para>

   <para>
    Les mots de passe de bases de données <productname>PostgreSQL</productname>
    sont distincts des mots de passe du système d'exploitation. Le mot de passe
    de chaque utilisateur est enregistré dans la table catalogue système
    <literal>pg_shadow</>. Les mots de passes 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">, par
    exemple <userinput>CREATE USER foo WITH PASSWORD 'secret';</userinput>. Par
    défaut, si aucun mot de passe n'a été fixé, le mot de passe enregistré sera
    nul et l'authentification par mot de passe échouera systématiquement pour
    cet utilisateur.
   </para>

  </sect2>

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

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

   <para><productname>Kerberos</productname> est un système d'authentification
sécurisé de standard industriel destiné à l'informatique distribuée sur un
réseau public. Une description du système <productname>Kerberos</productname>
est bien au-delà des objectifs de ce document&nbsp; c'est généralement assez complexe
(bien que puissant). La <ulink
url="http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html"> <acronym>FAQ</>
Kerberos</ulink> ou <ulink url="ftp://athena-dist.mit.edu">le projet Athena du
MIT</ulink> peuvent être un bon point de départ pour une exploration. Il existe
plusieurs sources de distribution <productname>Kerberos</>.  </para>

   <para>Bien que <productname>PostgreSQL</> supporte Kerberos 4 et 5, seul
Kerberos 5 est recommandé. Kerberos 4 est considéré peu sûr et n'est plus
recommandé pour un usage classique.    </para>

   <para>Pour utiliser <productname>Kerberos</>, son support doit être activé
au moment de la compilation.  Voir le <xref linkend="installation"> pour plus
d'informations. Kerberos 4 et 5 sont supportés mais une seule version peut être
activée lors d'une compilation.</para>

   <para><productname>PostgreSQL</> fonctionne comme un service Kerberos
normal.  Le nom du service principal est
<literal><replaceable>nom_service</>/<replaceable>nom_hote</>@<replaceable>domaine</></literal>,
où <replaceable>servicename</> est <literal>postgres</literal> (à moins qu'un
nom de service différent soit sélectionné lors de la configuration avec
<literal>./configure --with-krb-srvnam=quelquechose</>). <replaceable>nom_hote</>
est le nom de l'hôte pleinement qualifié (fully qualified host name) de la
machine serveur. Le domaine principal du service est le domaine préféré du
serveur.</para>

   <para>Les principaux clients doivent avoir leur nom d'utilisateur
<productname>PostgreSQL</> comme premier composant, par exemple
<literal>nomutilisateurpg/autreschoses@domaine</>. Actuellement, le domaine du client
n'est pas vérifié par <productname>PostgreSQL</>&nbsp;; ainsi si vous avez activé
l'authentification "cross-realm", chaque "principal" de chaque domaine qui peut
communiquer avec le vôtre sera accepté.  </para>

   <para>Assurez-vous que le fichier de clés du serveur est en lecture (et de
préférence en lecture seule) pour 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.
(Voir aussi <xref linkend="runtime-config">.) Par défaut le fichier est
<filename>/etc/srvtab</> si vous utilisez Kerberos 4 et
<filename>/usr/local/pgsql/etc/krb5.keytab</> (ou le
répertoire spécifié par <varname>sysconfdir</> à la compilation) avec Kerberos
5.  </para>

   <para>Pour générer le fichier keytab, utilisez par exemple (avec la version
5)&nbsp;: <screen> <prompt>kadmin% </><userinput>ank -randkey
postgres/server.my.domain.org</> <prompt>kadmin% </><userinput>ktadd -k
krb5.keytab postgres/server.my.domain.org</> </screen> Lisez la documentation
<productname>Kerberos</> pour les détails.  </para>

   <para>Lors de la connexion à la base de données, assurez-vous que vous avez
un ticket pour un "principal" correspondant au nom d'utilisateur de la base de
données demandé. Exemple : pour le nom d'utilisateur de la base
<literal>fred</>, les "principal" <literal>fred@EXAMPLE.COM</> et
<literal>fred/users.exemple.com@EXAMPLE.COM</> peuvent être utilisés pour
authentifier le serveur de bases de données.  </para>

   <para>Si vous utilisez <application>mod_auth_kerb</application> de <ulink
url="http://modauthkerb.sf.net">http://modauthkerb.sf.net</ulink> et
<application>mod_perl</application> sur votre serveur web
<productname>Apache</productname>, vous pouvez utiliser <literal>AuthType
KerberosV5SaveCredentials</literal> avec un script
<application>mod_perl</application>. Cela fournit un accès sûr aux bases de
données, sans demander de mots de passe supplémentaires.  </para>

  </sect2>

  <sect2 id="auth-ident"> <title>Authentification basée sur
l'identification</title>

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

   <para>La méthode d'authentification par identification fonctionne en
obtenant les noms d'utilisateurs du système d'exploitation, puis en déterminant
les noms d'utilisateurs de bases de données autorisés, en utilisant un fichier
de correspondance qui liste les paires d'utilisateurs correspondants.
Déterminer le nom d'utilisateur du client est le point critique en matière de
sécurité, et il fonctionne différemment selon le type de connexion.  </para>

   <sect3> <title>Authentification par identification sur TCP/IP</title>

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

   <para>Le défaut de cette procédure est qu'elle dépend de l'intégrité du
client&nbsp;: si la machine client est douteuse ou compromise, un attaquant peut
lancer n'importe quel programme sur le port 113 et renvoyer 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 client est
soumise à un contrôle strict et dans lesquels les administrateurs du système et
des bases de données opèrent en proche collaboration. En d'autres mots, vous
devez pouvoir faire confiance à la machine hébergeant le serveur
d'identification.  Considérez cet avertissement: <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>
    Quelques serveurs ident ont une option non standard qui font que le nom de
    l'utilisateur est renvoyé crypté en utilisant une clé que seul
    l'administrateur de la machine d'origine connaît. Cette option <emphasis>ne
    doit pas</> être utilisée lors de l'utilisation du serveur ident avec
    <productname>PostgreSQL</> car <productname>PostgreSQL</> n'a aucun moyen
    de décrire la chaîne renvoyée pour déterminer le réel nom de l'utilisateur.
   </para>

</sect3>

   <sect3> <title>Authentification par l'identification sur sockets
locaux</title>

   <para>Sur les systèmes supportant les requêtes <symbol>SO_PEERCRED</symbol>
pour les sockets du domaine Unix (actuellement <systemitem
class="osname">Linux</>, <systemitem class="osname">FreeBSD</>, <systemitem
class="osname">NetBSD</>, <systemitem class=osname>OpenBSD</> et <systemitem
class="osname">BSD/OS</>), l'authentification par identification peut aussi être
appliquée aux connexions locales. Dans ce cas, l'utilisation de
l'authentification par identification n'ajoute aucun risque lié à la sécurité.
</para>

    <para>
     Sur les systèmes sans requêtes <symbol>SO_PEERCRED</>, l'authentification
     par identification n'est disponible que pour les connexions TCP/IP. En
     complément, il est possible de préciser  <systemitem
     class="systemname">l'adresse localhost</> <systemitem
     class="systemname">127.0.0.1</> et d'établir une connexion à cette
     adresse. Vous pouvez avoir confiance en cette méthode si vous avez
     confiance dans le serveur ident local.
    </para>
   </sect3>

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

   <para>Lorsque vous utilisez l'authentification basée sur l'identification,
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 par le nom d'utilisateur de base de
données qu'il demande. Ceci est contrôlé par l'argument ident map qui suit le
mot clé <literal>ident</> 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 base de données du même nom (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 correspondance d'identité, qui est nommé
    par défaut <filename>pg_ident.conf</filename>
    <indexterm><primary>pg_ident.conf</primary></indexterm> et qui est stocké
    par défaut dans le répertoire data (il est possible de placer le fichier
    de correspondance ailleurs&nbsp;; voir le paramètre de configuration
    <xref linkend="guc-ident-file">). Ce fichier contient des lignes de la forme
    suivante&nbsp;:
<synopsis>
<replaceable>nom-correspondance</> <replaceable>nomutilisateur-ident</> <replaceable>base-donnee-utilisateur</>
</synopsis>
    Les commentaires et les espaces sont gérés de la façon habituelle dans le
    fichier <filename>pg_hba.conf</>. Le <replaceable>map-name</> est un
nom arbitraire qui sera utilisé pour se référer à cette correspondance dans
<filename>pg_hba.conf</filename>. Les deux autres champs spécifient quel
utilisateur du système d'exploitation est autorisé à se connecter sous quel nom
d'utilisateur de base de données. Le même <replaceable>nom-correspondance</>
peut être répété pour spécifier plusieurs correspondances d'utilisateurs 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
quand le processus serveur principal (<command>postmaster</>) reçoit un signal
<systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>.
Si vous éditez le fichier sur un système actif, vous aurez besoin de signaler au
<command>postmaster</> (en utilisant <literal>pg_ctl reload</> ou <literal>kill
-HUP</>) qu'il doit relire le fichier.  </para>

   <para>L'<xref linkend="example-pg-ident.conf"> montre un fichier
<filename>pg_ident.conf</filename> pouvant être utilisé conjointement avec le
fichier <filename>pg_hba.conf</> de l'<xref linkend="example-pg-hba.conf">. Dans
cette configuration d'exemple, n'importe qui connecté sur une machine du réseau
192.168 qui n'a pas de nom utilisateur Unix <literal>bryanh</>, <literal>ann</>,
ou <literal>robert</> ne pourrait obtenir d'accès. L'utilisateur Unix
<literal>robert</> ne serait autorisé à se connecter que lorsqu'il se connecte
sous l'utilisateur <productname>PostgreSQL</> <literal>bob</> et non
<literal>robert</> ni n'importe qui d'autre. <literal>ann</> ne serait autorisée
à se connecter qu'en tant que <literal>ann</>. L'utilisateur <literal>bryanh</>
ne serait autorisé à se connecter qu'en tant que <literal>bryanh</> lui-même ou
comme <literal>guest1</>.  </para>

   <example id="example-pg-ident.conf"> <title>Un fichier d'exemple
<filename>pg_ident.conf</></title> <programlisting>
# CORRESPONDANCE     NOMUTILISATEUR-IDENT    NOMUTILISATEUR-PG

omicron              bryanh                  bryanh 
omicron              ann                     ann
# bob a le nom d'utilisateur robert sur ces machines
omicron              robert                  bob
# bryanh peut aussi se connecter en tant que guest1
omicron              bryanh                  guest1
</programlisting> </example>
</sect3> </sect2>

  <sect2 id="auth-pam"> <title>Authentification PAM</title>

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

   <para>Cette méthode d'authentification fonctionne de façon similaire à
    <literal>password</literal> à ceci près qu'elle utilise PAM (Pluggable
    Authentication Modules) comme mécanisme d'authentification. Le nom du
    service PAM par défaut est <literal>postgresql</literal>. Vous pouvez
    éventuellement fournir votre nom de service grâce au mot clé <literal>pam</>
    du <filename>pg_hba.conf</filename>. PAM est seulement utilisé pour valider
    des paires nom utilisateur/mot de passe. Du coup, l'utilisateur doit déjà
    exister dans la base de données avant que PAM ne puisse être utilisé pour
    l'authentification. Pour plus d'informations sur PAM, merci de lire la
    <ulink url="http://www.kernel.org/pub/linux/libs/pam/">page
    <productname>Linux-PAM</></ulink> et la <ulink
    url="http://www.sun.com/software/solaris/pam/">page PAM <systemitem
    class="osname">Solaris</></ulink>.</para>
  </sect2>
 </sect1>

  <sect1 id="client-authentication-problems"> <title>Problèmes
d'authentification</title>

   <para>Les erreurs et problèmes d'authentification se manifestent
généralement par des messages d'erreurs tels que ceux qui suivent.  </para>

   <para>
<ProgramListing>
FATAL:  no pg_hba.conf entry for host "123.123.123.123", user "andym", database "testdb"
</ProgramListing>
    C'est ce que vous risquez le plus d'obtenir si vous parvenez à contacter
    le serveur mais qu'il refuse de vous parler. Comme le suggère le message,
    le serveur a refusé la demande de connexion parce qu'il n'a trouvé aucune
    entrée l'y autorisant dans son fichier de configuration
    <filename>pg_hba.conf</filename>.</para>

   <para>
<ProgramListing>
FATAL:  Password authentication failed for user "andym"
</ProgramListing>
    Les messages de ce type indiquent que vous avez contacté le serveur et
    qu'il veut vous parler mais pas avant que vous n'ayez franchi la méthode
    d'authentification spécifiée dans le fichier
    <filename>pg_hba.conf</filename>.  Vérifiez le mot de passe que vous avez
    fourni ou vérifiez votre logiciel d'identification ou votre logiciel Kerberos
    si les plaintes mentionnent l'un de ces types d'authentification.</para>

   <para>
<ProgramListing>
FATAL:  user "andym" does not exist
</ProgramListing>
    Le nom d'utilisateur indiqué n'a pas été trouvé.  </para>

   <para>
<ProgramListing>
FATAL:  database "testdb" does not exist
</ProgramListing>
    La base de données à laquelle vous essayez de vous connecter n'existe pas.
    Notez que si vous ne spécifiez pas un nom de base de données, le nom de la
    base par défaut est le nom de l'utilisateur de la base de données, ce qui
    peut être ou pas une bonne chose.</para>

   <tip>
    <para>Les traces du serveur contiennent plus d'informations sur une erreur
     d'authentification que ce qui est rapporté au client. Si vous avez des
     doutes sur les raisons d'un échec, vérifiez les traces.</para>
   </tip>

</sect1>

</chapter>