modules d'authentification enfichables (PAM)
Modules d'authentification enfichables (Pluggable authentication modules ou PAM) sont un mécanisme permettant d'intégrer plusieurs schémas d'authentification de bas niveau dans une API de haut niveau, qui permet aux programmes qui reposent sur l'authentification d'être écrits indépendamment du schéma d'authentification sous-jacent.
PAM se positionne en interface entre les applications et les méthodes d’authentification.
Une application demande à PAM si un utilisateur peut se connecter. PAM en fonction de sa configuration, appelle des modules fonctionnels qui vont exploiter une méthode d’authentification. Si le résultat est positif (l’utilisateur a fourni les bons éléments d’authentification), PAM renvoie l’autorisation de connexion à l’application.
Fichiers de configuration PAM
Le répertoire /etc/pam.d/ contient les fichiers de configuration PAM pour chaque application compatible PAM. Dans les versions précédentes de PAM, le fichier /etc/pam.conf était utilisé, mais ce fichier est désormais obsolète et n'est utilisé que si le répertoire /etc/pam.d/ n'existe pas.
Chaque application s’appuyant sur PAM aura besoin d’un fichier (en général du même nom que l’application) qui contiendra sa configuration PAM.
Format d’un fichier de /etc/pam.d
Le fichier contiendra autant de lignes qu’on souhaite appeler de modules avec pour chaque ligne la structure suivante :
type contrôle module arguments
- type : Représente le type d’action qui nécessite le recours à PAM. Les quatre valeurs possibles sont : auth, account, password et session.
- contrôle : Indique comment le module doit réagir au succès ou à l’échec de son exécution. Les valeurs courantes sont required, requisite, sufficient et optional.
- module : Le nom du module appelé. Le format normalisé est : pam_service.so, où service représente le nom courant du module.
- arguments : Paramètres optionnels envoyés au module pour modifier son fonctionnement.
Le programme compatible PAM est chargé de définir son nom de service et d'installer son propre fichier de configuration PAM dans le répertoire /etc/pam.d/. Par exemple, le programme login définit son nom de service comme login et installe le fichier de configuration PAM /etc/pam.d/login.
Extrait d’un fichier de configuration pam pour l’application login
devinfo@ubuntu:~$ sudo cat /etc/pam.d/login ... auth requisite pam_nologin.so ...
Dans cet exemple, il est question d’authentification (auth), l’exécution du module est requise (requisite), le module exploite le fichier pam_nologin.so.
Les types d’action de PAM
Quatre types d'interface de module PAM sont actuellement disponibles. Chacun d'eux correspond à un aspect différent du processus d'autorisation :
- auth : Cette interface de module authentifie les utilisateurs. Par exemple, il demande et vérifie la validité d'un mot de passe. Les modules dotés de cette interface peuvent également définir des informations d'identification, telles que des appartenances à des groupes ou des tickets Kerberos.
- account : Cette interface de module vérifie que l'accès est autorisé. Par exemple, il peut vérifier si un compte utilisateur a expiré ou si un utilisateur est autorisé à se connecter à un moment particulier de la journée.
- password : Cette interface de module est utilisée pour changer les mots de passe des utilisateurs.
- session : Cette interface de module configure et gère les sessions utilisateur. Les modules dotés de cette interface peuvent également effectuer des tâches supplémentaires nécessaires pour autoriser l'accès, comme le montage du répertoire personnel d'un utilisateur et la mise à disposition de la boîte aux lettres de l'utilisateur.
Les comportements des modules
Tous les modules PAM génèrent un résultat de réussite ou d'échec lorsqu'ils sont appelés. Les indicateurs de contrôle indiquent à PAM ce qu'il faut faire avec le résultat. Les modules peuvent être empilés dans un ordre particulier et les indicateurs de contrôle déterminent l'importance du succès ou de l'échec d'un module particulier pour l'objectif global d'authentification de l'utilisateur auprès du service.
Il existe quatre indicateurs de contrôle prédéfinis :
- required : Le résultat du module doit être réussi pour que l'authentification se poursuive. Si le test échoue à ce stade, l'utilisateur n'en est pas informé tant que les résultats de tous les tests de module faisant référence à cette interface ne sont pas terminés.
- requisite : Le résultat du module doit être réussi pour que l'authentification se poursuive. Cependant, si un test échoue à ce stade, l'utilisateur est immédiatement notifié avec un message reflétant le premier test de module requis échoué.
- sufficient : Le résultat du module est ignoré en cas d'échec. Cependant, si le résultat d'un module signalé comme suffisant est réussi et qu'aucun module précédent signalé comme requis n'a échoué, alors aucun autre résultat n'est requis et l'utilisateur est authentifié auprès du service.
- optional : Le résultat du module est ignoré. Un module marqué comme optional (facultatif) ne devient nécessaire pour une authentification réussie que lorsqu'aucun autre module ne fait référence à l'interface.
