PostgreSQLLa base de données la plus sophistiquée au monde.

Version anglaise

20.6. Authentification GSSAPI

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'utilisation de soit une couche d'authentification, chiffrée, soit uniquement une authentification. 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™ (voir hostgssenc) ou le chiffrement SSL sont utilisés, 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 16, Procédure d'installation du code source pour plus d'informations.

Quand GSSAPI™ passe par Kerberos™, il utilise un service principal standard au format nom_service/nom_hôte@domaine. 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 krbsrvname. (Voir aussi Section 33.1.2, « Mots clés de la chaîne de connexion ».) 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, « Compte utilisateur PostgreSQL™ »). 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, « Correspondances d'utilisateurs ».

Le support de GSSAPI doit être activé lors de la construction de PostgreSQL™ ; voir Chapitre 16, Procédure d'installation du code source 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, « Correspondances d'utilisateurs »). 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, « Correspondances d'utilisateurs » 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.