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
include
fichier
include_if_exists
fichier
include_dir
répertoire
Les commentaires, les blancs et les continuations de ligne 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.
Comme pour pg_hba.conf
, les lignes dans ce fichier
peuvent inclure des directives, en suivant les mêmes règles.
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é. La valeur all
peut être utilisé comme database-username
pour indiquer que, si system-username
correspond, alors cet utilisateur est autorisé à se connecter en tant
que n'importe quel utilisateur de base existant. Ajouter des guillemets à
all
lui fait perdre sa signification spéciale.
Si le champ database-username
commence avec un caractère +
, alors l'utilisateur du système d'exploitation
peut se connecter en tant que n'importe quel utilisateur appartenant à ce
rôle, de façon similaire à la façon dont sont traités les noms d'utilisateur
commençant par +
dans pg_hba.conf
.
De ce fait, une symbole +
signifie « correspond à tout
rôle membre direct ou indirect de ce rôle », alors qu'un nom sans
+
correspond uniquement à ce rôle spécifique. Mettre
entre guillemet un nom de rôle commençant par +
fait perdre
au +
sa signification spéciale.
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
(sous-expression entre parenthèses), qui 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
.
Mettre entre guillemets un database-username
contenant \1
ne fait pas perdre sa
signification spéciale à \1
.
Si le champ database-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 sur la syntaxe des expressions rationnelles dans
PostgreSQL. Il n'est pas possible d'utiliser
\1
pour utiliser une capture d'une expression rationnelle
sur system-username
pour une expression rationnelle
sur database-username
.
Gardez en tête que, par défaut, une expression rationnelle peut correspondre
à une petite partie d'une chaîne. Il est généralement conseillé d'utiliser
les jokers ^
et $
, comme indiqué dans
l'exemple ci-dessus, pour forcer une correspondance sur le nom entier de
l'utilisateur du système d'exploitation.
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.
La vue système pg_ident_file_mappings
peut être utile pour tester des modifications du fichier
pg_ident.conf
et pour diagnostiquer des problèmes si le
chargement du fichier n'a pas eu les effets désirés. Les lignes de la vue
avec le champ error
non NULL indiquent des
problèmes dans les lignes correspondantes du fichier.
Un fichier pg_ident.conf
qui pourrait être utilisé
avec le fichier pg_hba.conf
de
Exemple 21.1 est montré en
Exemple 21.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
.
Exemple 21.2. Un exemple de fichier pg_ident.conf
# 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