GSSAPI est un protocole du standard de l'industrie pour l'authentification sécurisée définie dans RFC 2743. PostgreSQL supporte GSSAPI avec l'authentification Kerberos suivant la RFC 1964. GSSAPI fournit une authentification automatique (single sign-on) 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 SSL est utilisé.
Le support de GSSAPI doit être activé quand PostgreSQL est compilé ; voir Chapitre 16 pour plus d'informations.
Quand GSSAPI passe par
Kerberos, il utilise un service principal standard
au format
.
Le serveur PostgreSQL acceptera n'importe quel service principal inclus dans le
fichier de clés utilisé par le serveur, mais il est nécessaire de faire attention de
spécifier les détails du bon service principal quand une connexion est effectuée
depuis le client utilisant le paramètre de connexion
nom_service
/nom_hôte
@domaine
krbsrvname
. (Voir aussi Section 34.1.2.)
La valeur par défaut à l'installation, postgres
,
peut être changée lors de la compilation en utilisant
./configure --with-krb-srvnam=
autrechose
.
Dans la plupart des environnements, ce paramètre n'a jamais besoin d'être
changé. Quelques implémentations de Kerberos peuvent nécessiter un nom de
service différent, par exemple Microsoft Active Directory qui réclame que
le nom de service soit en majuscule (POSTGRES
).
nom_hôte
est le nom d'hôte pleinement qualifié
(fully qualified host name)
de la machine serveur. Le domaine du service principal est le domaine
préféré du serveur.
Les principals du client peuvent être mis en correspondance avec
différents noms d'utilisateurs PostgreSQL grâce
au fichier de configuration pg_ident.conf
. Par
exemple, pgusername@realm
pourrait correspondre à
pgusername
. De la même façon, vous pouvez utiliser le
principal complet username@realm
comme nom de rôle dans
PostgreSQL sans aucune correspondance.
PostgreSQL supporte aussi un paramètre pour
supprimer le royaume du principal. Cette méthode est supportée pour des
raisons de compatibilité ascendante et est fortement déconseillé car il
est ensuite impossible de distinguer différents utilisateurs avec le même
nom d'utilisateur mais un domaine différent. Pour l'activer, configurez
include_realm
à 0. Pour des installations simples à un
seul royaume, le faire en combinant avec la configuration du paramètre
krb_realm
(qui vérifie que le royaume du principal
correspond exactement à ce qui est dans le paramètre
krb_realm
) est toujours sécurisé mais cette approche
offre moins de possibilités en comparaison à la spécification d'une
correspondance explicite.
Le fichier de clés du serveur doit être lisible (et de préférence
uniquement lisible, donc sans écriture possible) par le compte serveur
PostgreSQL (voir aussi la
Section 18.1). L'emplacement du fichier de clés est
indiqué grâce au paramètre de configuration
krb_server_keyfile. La valeur par défaut est
/usr/local/pgsql/etc/krb5.keytab
(ou tout autre
répertoire indiqué comme sysconfdir
lors de la
compilation). Pour des raisons de sécurité, il est recommandé d'utiliser un
fichier de clés séparé pour PostgreSQL
uniquement plutôt que d'ouvrir les droits sur le fichier de clés du
système.
Le fichier de clés est généré pour le logiciel Kerberos ; voir la documentation de Kerberos pour plus de détails. L'exemple suivant est valable pour des implémentations de Kerberos 5 compatible MIT :
kadmin%
ank -randkey postgres/server.my.domain.org
kadmin%
ktadd -k krb5.keytab postgres/server.my.domain.org
Lors de la connexion à la base de données, il faut s'assurer de posséder
un ticket pour le service principal correspondant au nom d'utilisateur de base
de données souhaité. Par exemple, pour le nom d'utilisateur PostgreSQL
fred
, le service principal fred@EXAMPLE.COM
pourrait se connecter. Pour autoriser aussi le service principal
fred/users.example.com@EXAMPLE.COM
, il faut utiliser une
correspondance de nom d'utilisateur, comme décrit dans Section 20.2.
Le support de GSSAPI doit être activé lors de la construction de PostgreSQL ; voir Chapitre 16 pour plus d'informations.
Les options de configuration suivantes sont supportées pour GSSAPI :
include_realm
Si configuré à 0, le nom du royaume provenant du principal de
l'utilisateur authentifié est supprimé avant d'être passé à la
correspondance du nom d'utilisateur (Section 20.2). Ceci n'est pas conseillé mais reste
disponible principalement pour des raisons de compatibilité ascendante
car ce n'est pas sûr dans des environnements avec plusieurs royaumes
sauf si krb_realm
est aussi utilisé. Il est
recommandé de laisser include_realm
configurer à sa
valeur par défaut et de fournir une correspondance explicite dans
pg_ident.conf
pour convertir les noms de principaux
en noms d'utilisateurs PostgreSQL.
compat_realm
Si configuré à 1, le nom, compatible SAM, du domaine (aussi connu en
tant que nom NetBIOS) est utilisé pour l'option
include_realm
. C'est la valeur par défaut. Si
configuré à 0, le vrai nom de royaume provenant de nom du principal
Kerberos est utilisé.
Ne désactivez pas cette option sauf si votre serveur est exécuté sous un compte domaine (ceci inclut les comptes de service virtuels sur un système membre du domaine) et si tous les clients s'authentifiant via SSPI utilisent aussi des comptes domaines. Dans le cas contraire, l'authentification va échouer.
upn_username
Si cette option est activée avec compat_realm
, le
nom de l'utilisateur provenant du UPN Kerberos est utilisé pour
l'authentification. Si elle est désactivée (par défaut), le nom
d'utilisateur provenant de l'UPN Kerberos est utilisé pour
l'authentification. Si elle est désactivée (par défaut), le nom
d'utilisateur compatible SAM est utilisé. Par défaut, ces deux noms
sont identiques pour les nouveaux comptes utilisateurs.
Notez que libpq utilise le nom compatible SAM si aucun nom d'utilisateur explicite n'est spécifié. Si vous utilisez la libpq ou un connecteur basé sur cette bibliothèque, vous devriez laisser cette option désactivée ou indiquer explicitement le nom d'utilisateur dans la chaîne de connexion.
map
Permet la mise en correspondance entre les noms système et base de
données. Voir Section 20.2 pour plus de détails.
Pour un principal GSSAPI/Kerberos, tel que
username@EXAMPLE.COM
(ou, moins communément,
username/hostbased@EXAMPLE.COM
), le nom d'utilisateur
utilisé pour la correspondance est
username@EXAMPLE.COM
(ou
username/hostbased@EXAMPLE.COM
, respectivement),
sauf si include_realm
a été configuré à 0, auquel
cas username
(ou
username/hostbased
) est ce qui est vu comme le nom
d'utilisateur du système lors de la recherche de correspondance.
krb_realm
Configure le domaine pour la correspondance du principal de l'utilisateur. Si ce paramètre est configuré, seuls les utilisateurs de ce domaine seront acceptés. S'il n'est pas configuré, les utilisateurs de tout domaine peuvent se connecter, à condition que la correspondance du nom de l'utilisateur est faite.