PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 10.23 » Administration du serveur » Authentification du client » Méthodes d'authentification

20.3. Méthodes d'authentification

Les sous-sections suivantes décrivent les méthodes d'authentification en détail.

20.3.1. Authentification trust

Quand l'authentification trust est utilisée, PostgreSQL considère que quiconque peut se connecter au serveur est autorisé à accéder à la base de données quel que soit le nom d'utilisateur de bases de données qu'il fournit (même les noms des super-utilisateurs). Les restrictions apportées dans les colonnes database et user continuent évidemment de s'appliquer. Cette méthode ne doit être utilisée que si le système assure un contrôle adéquat des connexions au serveur.

L'authentification trust est appropriée et très pratique pour les connexions locales sur une station de travail mono-utilisateur. Elle n'est généralement pas appropriée en soi sur une machine multi-utilisateur. Cependant, trust peut tout de même être utilisé sur une machine multi-utilisateur, si l'accès au fichier socket de domaine Unix est restreint par les permissions du système de fichiers. Pour ce faire, on peut positionner les paramètres de configuration unix_socket_permissions (et au besoin unix_socket_group) comme cela est décrit dans la Section 19.3. On peut également positionner le paramètre de configuration unix_socket_directories pour placer le fichier de socket dans un répertoire à l'accès convenablement restreint.

Le réglage des droits du système de fichiers n'a d'intérêt que le cas de connexions par les sockets Unix. Les droits du système de fichiers ne restreignent pas les connexions TCP/IP locales. Ainsi, pour utiliser les droits du système de fichiers pour assurer la sécurité locale, il faut supprimer la ligne host ...127.0.0.1 ... de pg_hba.conf ou la modifier pour utiliser une méthode d'authentification différente de trust.

L'authentification trust n'est envisageable, pour les connexions TCP/IP, que si chaque utilisateur de chaque machine autorisée à se connecter au serveur par les lignes trust du fichier pg_hba.conf est digne de confiance. Il est rarement raisonnable d'utiliser trust pour les connexions autres que celles issues de localhost (127.0.0.1).

20.3.2. Authentification par mot de passe

Il existe plusieurs méthodes d'authentification basées sur un mot de passe. Ces méthodes opèrent de façon similaire mais diffèrent sur la façon dont les mots de passe des utilisateurs sont enregistrés sur le serveur et comment le mot de passe fourni par un client est envoyé au serveur.

scram-sha-256

La méthode scram-sha-256 réalise une authentification SCRAM-SHA-256, tel qu'elle est décrite dans la RFC 7677. Il s'agit d'un système de question/réponse qui empêche la récupération du mot de passe sur des connexions non sécurisées et supporte l'enregistrement des mots de passe sur le serveur avec un hachage cryptographique normalement sécurisé.

C'est actuellement la méthode interne la plus sécurisée, mais elle n'est pas supportée par les anciennes bibliothèques clients.

md5

La méthode md5 utilise un mécanisme de question/réponse moins sécurisé. Il empêche la récupération du mot de passe et évite d'enregistrer les mots de passe en clair sur le serveur, mais ne fournit aucune protection si l'attaquant réussit à voler le mot de passe haché du serveur. De plus, l'algorithme de hachage MD5 n'est plus considéré de nos jours comme suffisamment sécurisé avec des attaques déterminées.

La méthode md5 ne peut pas être utilisé avec la fonctionnalité db_user_namespace.

Pour faciliter la transition de la méthode md5 à la méthode SCRAM, si md5 est indiqué comme méthode d'authentification dans pg_hba.conf mais que le mot de passe de l'utilisateur sur le serveur est chiffré avec SCRAM (voir ci-dessous), l'authentification SCRAM est automatiquement utilisée à la place.

password

La méthode password envoie le mot de passe en clair et est de ce fait vulnérable aux attaques de type « sniffing ». Elle doit être évitée chaque fois que possible. Si la connexion est protégée par le chiffrage SSL, alors password peut être utilisé de façon sécurisée. (Ceci étant dit, l'authentification par certificat SSL serait un meilleur choix en cas d'utilisation de SSL).

Les mots de passe PostgreSQL sont distincts des mots de passe du système d'exploitation. Le mot de passe de chaque utilisateur est enregistré dans le catalogue système pg_authid. Ils peuvent être gérés avec les commandes SQL CREATE USER et ALTER ROLE. Ainsi, par exemple, CREATE USER foo WITH PASSWORD 'secret'; ou la méta-commande \password de psql. Si aucun mot de passe n'est enregistré pour un utilisateur, le mot de passe enregistré est nul et l'authentification par mot de passe échoue systématiquement pour cet utilisateur.

La disponibilité des différentes méthodes d'authentification basées sur des mots de passe dépend de comment un mot de passe utilisateur est chiffré sur le serveur (ou haché pour être plus précis). Ceci est contrôlé par le paramètre de configuration password_encryption au moment où le mot de passe est configuré. Si un mot de passe est chiffré en utilisant le paramètre scram- sha-256, alors il peut être utilisé par les méthodes d'authentification scram-sha-256 et password (mais la transmission du mot de passe sera en clair dans ce dernier cas). La méthode d'authentification md5 sera automatiquement basculée vers la méthode scram-sha-256 dans ce cas, comme expliqué ci-dessus, donc cela fonctionnera aussi. Si un mot de passe était chiffré en utilisant la configuration md5, alors il peut seulement être utilisé pour les méthodes d'authentification md5 et password (de nouveau, avec le mot de passe transmis en clair dans ce dernier cas). (Les anciennes versions de PostgreSQL supportaient le stockage en clair du mot de passe sur le serveur. Ceci n'est plus possible.) Pour vérifier les hachages de mot de passe actuellement enregistrés, voir le catalogue système pg_authid.

Pour mettre à jour une installation existante de md5 vers scram-sha-256, après s'être assuré que toutes les bibliothèques courantes sont suffisamment récentes pour supporter SCRAM, configurez password_encryption = 'scram-sha-256' dans postgresql.conf, demandez à chaque utilisateur de configurer un nouveau mot de passe, et modifiez la méthode d'authentification dans pg_hba.conf avec scram-sha-256.

20.3.3. 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 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 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.) 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.

20.3.4. Authentification SSPI

SSPI est une technologie Windows pour l'authentification sécurisée avec single sign-on. PostgreSQL utilise SSPI dans un mode de négociation (negotiate) qui utilise Kerberos si possible et NTLM sinon. L'authentification SSPI ne fonctionne que lorsque serveur et client utilisent Windows ou, sur les autres plateformes, quand GSSAPI est disponible.

Lorsque Kerberos est utilisé, SSPI fonctionne de la même façon que GSSAPI. Voir Section 20.3.3 pour les détails.

Les options de configuration suivantes sont supportées pour SSPI :

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é aux utilisateurs de laisser include_realm configuré à sa valeur par défaut (1) et de fournir une correspondance explicite dans pg_ident.conf.

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.

20.3.5. Authentification fondée sur ident

La méthode d'authentification ident fonctionne en obtenant le nom de l'opérateur du système depuis le serveur ident distant et en l'appliquant comme nom de l'utilisateur de la base de données (et après une éventuelle mise en correspondance). Cette méthode n'est supportée que pour les connexions TCP/IP.

Note

Lorsqu'ident est spécifié pour une connexion locale (c'est-à-dire non TCP/IP), l'authentification peer (voir Section 20.3.6) lui est automatiquement substituée.

Les options de configuration suivantes sont supportées pour ident :

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.

Le « protocole d'identification » est décrit dans la RFC 1413. Théoriquement, chaque système d'exploitation de type Unix contient un serveur ident qui écoute par défaut sur le port TCP 113. La fonctionnalité basique d'un serveur ident est de répondre aux questions telles que : « Quel utilisateur a initié la connexion qui sort du port X et se connecte à mon port Y? ». Puisque PostgreSQL connaît X et Y dès lors qu'une connexion physique est établie, il peut interroger le serveur ident de l'hôte du client qui se connecte et peut ainsi théoriquement déterminer l'utilisateur du système d'exploitation pour n'importe quelle connexion.

Le revers de cette procédure est qu'elle dépend de l'intégrité du client : si la machine cliente est douteuse ou compromise, un attaquant peut lancer n'importe quel programme sur le port 113 et retourner un nom d'utilisateur de son choix. Cette méthode d'authentification n'est, par conséquent, appropriée que dans le cas de réseaux fermés dans lesquels chaque machine cliente est soumise à un contrôle strict et dans lesquels les administrateurs système et de bases de données opèrent en étroite collaboration. En d'autres mots, il faut pouvoir faire confiance à la machine hébergeant le serveur d'identification. Cet avertissement doit être gardé à l'esprit :

 

Le protocole d'identification n'a pas vocation à être un protocole d'autorisation ou de contrôle d'accès.

 
 --RFC 1413

Certains serveurs ident ont une option non standard qui chiffre le nom de l'utilisateur retourné à l'aide d'une clé connue du seul administrateur de la machine dont émane la connexion. Cette option ne doit pas être employée lorsque le serveur ident est utilisé avec PostgreSQL car PostgreSQL n'a aucun moyen de déchiffrer la chaîne renvoyée pour déterminer le nom réel de l'utilisateur.

20.3.6. Peer Authentication

La méthode d'authentification peer utilise les services du système d'exploitation afin d'obtenir le nom de l'opérateur ayant lancé la commande client de connexion et l'utilise (après une éventuelle mise en correspondance) comme nom d'utilisateur de la base de données. Cette méthode n'est supportée que pour les connexions locales.

Les options de configuration suivantes sont supportées pour l'authentification peer :

map

Autorise la mise en correspondance entre le nom d'utilisateur fourni par le système d'exploitation et le nom d'utilisateur pour la base de données. Voir Section 20.2 pour plus de détails.

L'authentification peer n'est disponible que sur les systèmes d'exploitation fournissant la fonction getpeereid(), le paramètre SO_PEERCRED pour les sockets ou un mécanisme similaire. Actuellement, cela inclut Linux, la plupart des variantes BSD (et donc macOS), ainsi que Solaris.

20.3.7. Authentification LDAP

Ce mécanisme d'authentification opère de façon similaire à password à ceci près qu'il utilise LDAP comme méthode de vérification des mots de passe. LDAP n'est utilisé que pour valider les paires nom d'utilisateur/mot de passe. De ce fait, pour pouvoir utiliser LDAP comme méthode d'authentification, l'utilisateur doit préalablement exister dans la base.

L'authentification LDAP peut opérer en deux modes. Dans le premier mode, que nous appelerons le mode « simple bind », le serveur fera un « bind » sur le nom distingué comme préfixe nom_utilisateur suffixe. Typiquement, le paramètre prefix est utilisé pour spécifier cn= ou DOMAIN\ dans un environnement Active Directory. suffix est utilisé pour spécifier le reste du DN dans un environnement autre qu'Active Directory.

Dans le second mode, que nous appelerons mode « search+bind », le serveur commence un « bind » sur le répertoire LDAP avec un nom d'utilisateur et un mot de passe fixés, qu'il indique à ldapbinddn et ldapbindpasswd. Il réalise une recherche de l'utilisateur en essayant de se connecter à la base de données. Si aucun utilisateur et aucun mot de passe n'est configuré, un « bind » anonyme sera tenté sur le répertoire. La recherche sera réalisée sur le sous-arbre sur ldapbasedn, et essaiera une correspondance exacte de l'attribut indiqué par ldapsearchattribute. Une fois que l'utilisateur a été trouvé lors de cette recherche, le serveur se déconnecte et effectue un nouveau « bind » au répertoire en tant que cet utilisateur, en utilisant le mot de passe indiqué par le client pour vérifier que la chaîne de connexion est correcte. Ce mode est identique à celui utilisé par les schémas d'authentification LDAP dans les autres logiciels, tels que les modules Apache mod_authnz_ldap et pam_ldap. Cette méthode permet une plus grande flexibilité sur l'emplacement des objets utilisateurs dans le répertoire mais demandera deux connexions au serveur LDAP.

Les options de configuration suivantes sont utilisées dans les deux modes :

ldapserver

Noms ou adresses IP des serveurs LDAP auxquels se connecter. Plusieurs serveurs peuvent être indiqués, en les séparant par des espaces.

ldapport

Numéro de port du serveur LDAP auquel se connecter. Si aucun port n'est spécifié, le port par défaut de la bibliothèque LDAP sera utilisé.

ldaptls

Positionnez à 1 pour que la connexion entre PostgreSQL et le serveur LDAP utilise du chiffrage TLS. Notez que ceci ne chiffre que le trafic jusqu'au serveur LDAP -- la connexion vers le client peut toujours ne pas être chiffrée sauf si SSL est utilisé.

Les options suivantes sont utilisées uniquement dans le mode « simple bind » :

ldapprefix

Chaîne à préfixer au nom de l'utilisateur pour former le DN utilisé comme lien lors d'une simple authentification bind.

ldapsuffix

Chaîne à suffixer au nom de l'utilisateur pour former le DN utilisé comme lien lors d'une simple authentification bind.

Les options suivantes sont utilisées uniquement dans le mode « search+bind » :

ldapbasedn

Racine DN pour commencer la recherche de l'utilisateur lors d'une authentification search+bind.

ldapbinddn

DN de l'utilisateur pour se lier au répertoire avec lequel effectuer la recherche lors d'une authentification search+bind.

ldapbindpasswd

Mot de passe de l'utilisateur pour se lier au répertoire avec lequel effectuer la recherche lors d'une authentification search+bind.

ldapsearchattribute

Attribut à faire correspondre au nom d'utilisateur dans la recherche lors d'une authentification search+bind. Si aucun attribut n'est indiqué, l'attribut uid sera utilisé.

ldapurl

Une URL LDAP dont le format est spécifié par la RFC 4516. C'est une autre façon d'écrire certaines options LDAP d'une façon plus compacte et standard. Le format est :

ldap://hote[:port]/basedn[?[attribut][?[scope]]]
        

scope doit faire partie des possibilités suivantes : base, one, sub. Ce sera généralement la dernière possibilité. Seulement un attribut est utilisé. Quelques autres composants des URL LDAP standards comme les filtres et les extensions ne sont pas supportés.

Pour les « bind » non anonymes, ldapbinddn et ldapbindpasswd doivent être spécifiées comme des options séparées.

Pour utiliser les connexions LDAP chiffrées, l'option ldaptls doit être utilisée avec ldapurl. Le schéma d'URL ldaps (connexion SSL directe) n'est pas supporté.

Les URL LDAP sont actuellement seulement supportées par OpenLDAP, et pas sous Windows.

Mixer les options de configurations du mode « simple bind » et du mode « search+bind » est une erreur.

Voici un exemple de configuration LDAP pour le mode « simple bind » :

host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
    

Quand une connexion au serveur de base de données est demandée en tant que un_utilisateur, PostgreSQL tentera un « bind » vers le serveur LDAP en utilisant le DN cn=un_utilisateur, dc=example, dc=net et le mot de passe fourni par le client. Si cette connexion réussit, l'accès à la base de données est accepté.

Voici un exemple de configuration LDAP pour le mode « search+bind » :

host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid
    

Quand une connexion au serveur de base de données est tentée en tant que un_utilisateur, PostgreSQL tentera un « bind » anonyme (car ldapbinddn n'a pas été précisé) au serveur LDAP, effectuera une recherche pour (uid=un_utilisateur) sous le DN de base spécifié. Si une entrée est trouvée, il tentera alors de faire un « bind » en utilisant l'information trouvée et le mot de passe fourni par le client. Si cette deuxième connexion réussit, l'accès à la base est autorisé.

Voici la même configuration « search+bind » écrite sous la forme d'une URL :

host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
    

D'autres logiciels qui supportent l'authentification LDAP utilisent le même format d'URL donc cela facilitera le partage de configuration.

Astuce

Comme LDAP utilise souvent des virgules et des espaces pour séparer les différentes parties d'un DN, il est souvent nécessaire d'utiliser des paramètres entourés de guillemets durant le paramétrage des options LDAP, comme montré dans les exemples.

20.3.8. Authentification RADIUS

Cette méthode d'authentification opère de façon similaire à password sauf qu'il existe la méthode RADIUS pour la vérification du mot de passe. RADIUS est seulement utilisé pour valider des pairs nom utilisateur / mot de passe. Du coup, l'utilisateur doit déjà exister dans la base de données avant que RADIUS puisse être utilisé pour l'authentification.

Lors de l'utilisation de l'authentification RADIUS, un message de demande d'accès (Access Request) sera envoyé au serveur RADIUS configuré. Cette demande sera du type « authentification seule » (Authenticate Only) et incluera les paramètres pour le nom de l'utilisateur, son mot de passe (chiffré) et un identifiant NAS (NAS Identifier). La demande sera chiffrée en utilisant un secret partagé avec le serveur. Le serveur RADIUS répond à cette demande avoir soit Access Accept soit Access Reject. Il n'y a pas de support des comptes RADIUS.

Plusieurs serveurs RADIUS peuvent être spécifiés, auquel cas ils seront testés de manière séquentielle. Si une réponse négative est reçue d'un serveur, l'authentification échouera. Si aucune réponse n'est reçue, le serveur qui suit dans la liste sera essayé. Pour spécifier plusieurs serveurs, séparez les noms de serveurs par des virgules et placez la liste entre guillemets double. Si plusieurs serveurs sont spécifiés, toutes les autres options RADIUS peuvent également être indiquées en tant que liste séparée par des virgules, pour s'appliquer individuellement à chaque serveur. Elles peuvent également être spécifiées indépendemment. Dans ce cas, elles seront appliquées à tous les serveurs.

Les options de configuration suivantes sont supportées par RADIUS :

radiusservers

Les noms DNS et/ou adresses IP des serveurs RADIUS pour l'authentification. Ce paramètre est requis.

radiussecrets

Les secrets partagés utilisés lors de discussions sécurisées avec les serveurs RADIUS. Il doit y avoir exactement la même valeur sur le serveur PostgreSQL et sur le serveur RADIUS. Il est recommandé d'utiliser une chaîne d'au moins 16 caractères. Ce paramètre est requis.

Note

Le vecteur de chiffrement utilisé sera un chiffrement fort seulement si PostgreSQL a été compilé avec le support d'OpenSSL. Dans les autres cas, la transmission au serveur RADIUS peut seulement être considérée comme caché, et non pas sécurisé, et des mesures de sécurité externes doivent être appliquées si nécessaire.

radiusports

Les numéros de port sur les serveurs RADIUS pour la connexion. Si aucun port n'est indiqué, le port RADIUS par défaut (1812) sera utilisé.

radiusidentifiers

Les chaînes à utiliser comme identifiants NAS (NAS Identifier) dans les demandes RADIUS. Ce paramètre peut être utilisé, par exemple, pour identifier l'instance auquel l'utilisateur tente de se connecter. C'est utilisable pour des vérifications sur les serveurs RADIUS. Si aucune identifiant n'est spécifié, la valeur par défaut, postgresql, sera utilisée.

S'il est nécessaire d'avoir une virgule ou un espace blanc dans la valeur d'un paramètre RADIUS, ceci peut se faire en entourant la valeur de guillemets doubles, mais ceci peut devenir compliqué car deux niveaux de guillemets doubles sont maintenant nécessaires. Voici un exemple d'espace bland dans les chaînes de secret RADIUS :

host ... radius radiusservers="server1,server2" radiussecrets="""secret one"",""secret two"""
    

20.3.9. Authentification de certificat

Cette méthode d'authentification utilise des clients SSL pour procéder à l'authentification. Elle n'est par conséquent disponible que pour les connexions SSL. Quand cette méthode est utilisée, le serveur exigera que le client fournisse un certificat valide et de confiance. Aucune invite de saisie de mot de passe ne sera envoyée au client. L'attribut cn (Common Name) du certificat sera comparé au nom d'utilisateur de base de données demandé. S'ils correspondent, la connexion sera autorisée. La correspondance des noms d'utilisateurs peut être utilisé pour permettre au cn d'être différent du nom d'utilisateur de la base de données.

Les options de configuration suivantes sont supportées pour l'authentification par certificat SSL :

map

Permet la correspondance entre les noms d'utilisateur système et les noms d'utilisateurs de bases de données. Voir Section 20.2 pour les détails.

Dans un enregistrement de pg_hba.conf indiquant une authentification par certificat, l'option d'authentification clientcert est supposée valoir 1, et elle ne peut pas être désactivée car un certificat client est nécessaire pour cette méthode. Ce que la méthode cert ajoute au test basique de validité du certificat clientcert est une vérification que l'attribut cn correspond à un nom d'utilisateur de la base.

20.3.10. Authentification PAM

Ce mécanisme d'authentification fonctionne de façon similaire à password à ceci près qu'il utilise PAM (Pluggable Authentication Modules) comme méthode d'authentification. Le nom du service PAM par défaut est postgresql. PAM n'est utilisé que pour valider des paires nom utilisateur/mot de passe et en option le nom de l'hôte distant connecté ou de l'adresse IP. De ce fait, avant de pouvoir utiliser PAM pour l'authentification, l'utilisateur doit préalablement exister dans la base de données. Pour plus d'informations sur PAM, merci de lire la page Linux-PAM.

Les options suivantes sont supportées pour PAM :

pamservice

Nom de service PAM.

pam_use_hostname

Détermine si l'adresse IP ou le nom d'hôte distant est fourni aux modules PAM via l'élément PAM_RHOST. Par défaut, l'adresse IP est utilisé. Configurez cette option à 1 pour utiliser à la place le nom d'hôte résolu. La résolution de nom d'hôte peut amener des délais de connexion. (La plupart des configurations PAM n'utilise pas cette information, donc il est seulement nécessaire de considérer ce paramètre si une configuration PAM a été créée spécifiquement pour l'utiliser.)

Note

Si PAM est configuré pour lire /etc/shadow, l'authentification échoue car le serveur PostgreSQL est exécuté en tant qu'utilisateur standard. Ce n'est toutefois pas un problème quand PAM est configuré pour utiliser LDAP ou les autres méthodes d'authentification.

20.3.11. Authentification BSD

Cette méthode d'authentification opère de façon similaire à password sauf qu'elle utilise l'authentification BSD pour vérifier le mot de passe. L'authentification BSD est seulement utilisée pour valider la paire nom d'utilisateur/mot de passe. De ce fait, le rôle de l'utilisation doit déjà exister dans la base de données avant que l'authentification BSD puisse être utilisée pour l'authentification. Cette méthode est actuellement uniquement disponible sur OpenBSD.

L'authentification BSD dans PostgreSQL utilise le type de login auth-postgresql et s'authentifie avec la classe de login postgresql si c'est défini dans login.conf. Par défaut, cette classe de login n'existe pas, et PostgreSQL utilisera la classe de login par défaut.

Note

Pour utiliser l'authentification BSD, le compte utilisateur PostgreSQL (c'est-à-dire l'utilisateur système qui exécute le serveur) doit d'abord être ajouté dans le groupe auth. Le groupe auth existe par défaut sur les systèmes OpenBSD.