GSSAPI est un protocole du standard de l'industrie pour l'authentification sécurisée définie dans RFC 2743. PostgreSQL supporte GSSAPI pour l'authentification, le chiffrement des communications, ou les deux. GSSAPI fournit une authentification automatique (single sign-on) pour les systèmes qui le supportent. L'authentification elle-même est sécurisée. Si le chiffrement GSSAPI ou le chiffrement SSL est utilisé, les données envoyées au travers de la connexion à la base de données seront chiffrées, sinon elles ne le seront pas.
Le support de GSSAPI doit être activé quand PostgreSQL est compilé ; voir Chapitre 17 pour plus d'informations.
Quand GSSAPI passe par
Kerberos, il utilise un principal service
standard au format
nom_service/nom_hôte@domaine
Lors de la connexion, le client doit connaître le nom du principal du
serveur où il souhaite se connecter. La partie
servicename est habituellement
postgres, mais une autre valeur peut être sélectionnée
via le paramètre de connexion krbsrvname de
libpq. La partie
hostname est le nom d'hôte complètement qualifié
auquel libpq se connecte. Le nom de royaume est
le royaume préféré indiqué dans le fichier de configuration Kerberos
accessible au client.
Le client aura aussi un nom de principal pour sa propre identité (et il
doit avoir un ticket valide pour ce principal). Pour utiliser
GSSAPI pour l'authentification, le principal du
client doit être associé avec un nom d'utilisateur de base
PostgreSQL. Le fichier de configuration
pg_ident.conf peut être utilisé pour établir une
correspondance entre les principaux et les noms d'utilisateurs. 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 la correspondance
entre principaux de clients et noms d'utilisateur en supprimant 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.
L'emplacement du fichier keytab du serveur est indiqué grâce au paramètre de configuration krb_server_keyfile. 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'autoriser le serveur à lire le fichier keytab du système. Assurez-vous que le fichier keytab du serveur est lisible (et de préférence seulement lisible, pas modifiable) par le compte serveur PostgreSQL (voir aussi Section 18.1).
Le fichier de clés est généré en utilisant le logiciel Kerberos ; voir la documentation de Kerberos pour plus de détails. L'exemple suivant montre comment le faire en utilisant l'outil kadmin des implémentations compatibles MIT de Kerberos :
kadmin%addprinc -randkey postgres/server.my.domain.orgkadmin%ktadd -k krb5.keytab postgres/server.my.domain.org
Les options d'authentification suivantes sont supportées pour la méthode d'authentification 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 principaux clients et les
noms d'utilisateurs de base. 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_realmConfigure 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.
En plus de ces paramètres, qui peuvent être différents pour différentes
entrées pg_hba.conf, il existe le paramètre serveur de
configuration krb_caseins_users. S'il est configuré à
true, les principaux clients sont comparés aux entrées de la carte
utilisateurs, sans attention à la casse. Si krb_realm
est configuré, il est aussi comparé sans attention à la casse.