Lorsqu'on utilise une authentification externe telle que Ident ou GSSAPI, le nom de l'utilisateur du système d'exploitation qui a initié la connexion peut ne pas être le même que celui de l'utilisateur de la base à laquelle il tente de se connecter. Dans ce cas, une table de correspondance d'identités peut être mise en place pour faire correspondre le nom d'utilisateur système au nom d'utilisateur base de donnée. Pour utiliser une table de correspondance d'identités, spécifiez map=nom-table dans le champ options de pg_hba.conf. Cette option est supportée pour toutes les méthodes d'authentification qui reçoivent des noms d'utilisateurs externes. Comme différentes correspondances peuvent être nécessaires pour différentes connexions, le nom de la table à utiliser doit être spécifié dans le paramètre nom-table de pg_hba.conf afin d'indiquer quelle table utiliser pour chaque connexion.

Les tables de correspondance de noms d'utilisateurs sont définies dans le fichier de correspondance, qui par défaut s'appelle pg_ident.conf et est stocké dans le répertoire de données du cluster. (Toutefois, il est possible de placer la table de correspondance ailleurs ; voir le paramètre de configuration ident_file.) Le fichier de table de correspondance contient des lignes de la forme suivante :

nom-table nom-d-utilisateur-systeme nom-d-utilisateur-base
   

Les commentaires et les blancs sont traités de la même façon que dans pg_hba.conf. Le nom-table est un nom arbitraire qui sera utilisé pour faire référence à cette table de correspondance dans pg_hba.conf. Les deux autres champs spécifient un nom d'utilisateur du système d'exploitation et un nom d'utilisateur de la base de données correspondant. Le même nom-correspondance peut être utilisé de façon répétée pour indiquer plusieurs correspondances d'utilisateur dans la même carte.

Il n'y a aucune restriction sur le nombre d'utilisateurs de base de données auxquels un utilisateur du système d'exploitation peut correspondre et vice-versa. Du coup, les entrées dans une carte signifient que « cet utilisateur du système d'exploitation est autorisé à se connecter en tant que cet utilisateur de la base de données », plutôt que supposer qu'ils sont équivalents. La connexion sera autorisée s'il existe une entrée dans la carte qui correspond au nom d'utilisateur obtenu à partir du système d'authentification externe pour le nom de l'utilisateur de la base de données que l'utilisateur a indiqué.

Si le champ system-username commence avec un slash (/), le reste du champ est traité comme une expression rationnelle. (Voir Section 9.7.3.1 pour les détails de la syntaxe des expressions rationnelles avec PostgreSQL.). L'expression rationnelle peut inclure une copie simple ou une sous-expression entre parenthèses. La portion du nom d'utilisateur système qui correspond à la copie peut ensuite être référencée dans le champ database-username avec le joker \1 (antislash-un). Ceci permet la correspondance de plusieurs noms d'utilisateurs sur une seule ligne, ce qui est particulièrement utile pour les substitutions simples. Par exemple, ces entrées

mymap   /^(.*)@mydomain\.com$      \1
mymap   /^(.*)@otherdomain\.com$   guest
   

supprimeront la partie domaine pour les utilisateurs de système d'exploitation dont le nom finissent avec @mydomain.com, et permettront aux utilisateurs dont le nom se termine avec @otherdomain.com de se connecter en tant que guest.

Le fichier pg_ident.conf est lu au démarrage et quand le processus principal du serveur reçoit un signal SIGHUP. Si vous éditez le fichier sur un système en cours d'utilisation, vous devez notifier le postmaster (en utilisantpg_ctl reload, en appelant la fonction SQL pg_reload_conf(), ou kill -HUP) pour lui faire relire le fichier.

Un fichier pg_ident.conf qui pourrait être utilisé avec le fichier pg_hba.conf de Exemple 20.1 est montré en Exemple 20.2. Dans cet exemple, toute personne connectée sur une machine du réseau 192.168 qui n'a pas le nom d'utilisateur du système d'exploitation bryanh, ann, ou robert verrait son accès refusé. L'utilisateur Unix robert ne verrait son accès autorisé que lorsqu'il essaie de se connecter en tant qu'utilisateur PostgreSQL bob, pas en tant que robert ou qui que ce soit d'autre. ann ne serait autorisée à se connecter qu'en tant que ann. L'utilisateur bryanh aurait le droit de se connecter soit en tant que bryanh, soit en tant que guest1.

# MAPNAME     SYSTEM-USERNAME   PG-USERNAME

omicron       bryanh            bryanh
omicron       ann               ann
# bob has user name robert on these machines
omicron       robert            bob
# bryanh can also connect as guest1
omicron       bryanh            guest1