Reauthentification
Certaines zones de GLPI sont plus sensibles que d'autres : comptes utilisateurs, profils et droits, groupes, paramètres d'authentification, plugins, journaux système, configuration générale.
Être connecté ne suffit plus pour y accéder. Lorsque vous ouvrez l'une de ces pages — ou déclenchez l'une de ces actions — GLPI vous demande de prouver, une fois de plus, que c'est bien vous. Cette courte étape supplémentaire s'appelle la ré-authentification (familièrement « mode sudo », par analogie avec la commande sudo sous Linux).
Une fois cette étape franchie, vous disposez d'une fenêtre de 15 minutes pendant laquelle les zones sensibles s'ouvrent sans redemander de vérification.
Quelle en est l'utilité ?
Votre session GLPI est une clé. Tant qu'elle est ouverte, quiconque s'en empare peut agir à votre place. La ré-authentification limite ce que cette seule clé permet de faire :
Poste de travail sans surveillance. Une session laissée ouverte sur un ordinateur déverrouillé peut permettre de consulter des tickets, mais pas d'accorder un profil, de créer un compte administrateur ou d'installer un plugin.
Session volée ou rejouée. Si un cookie de session fuite, l'attaquant détient la session mais pas votre mot de passe ni votre application d'authentification. L'élévation de privilèges est bloquée.
Lien ou URL piégé. Un lien reçu par mail, un message de chat, une image sur un autre site peut amener votre navigateur à envoyer une requête à GLPI en votre nom — par exemple « créer ce compte administrateur » ou « attribuer ce profil ». Une telle requête voyage avec votre session et pouvait donc jusqu'ici paraître légitime. Elle se heurte désormais à l'invite, et l'auteur du lien ne peut ni saisir votre mot de passe ni votre code 2FA à votre place.
Script injecté (XSS). Si un script malveillant parvient à s'exécuter dans une page GLPI — via un champ rempli par quelqu'un d'autre, un plugin compromis, une extension de navigateur — il hérite de votre session et peut envoyer des requêtes sans que vous vous en aperceviez. Les actions sensibles ne suivent plus. Mieux : une requête envoyée en arrière-plan (AJAX) ne peut pas afficher l'invite, donc GLPI refuse purement et simplement l'action plutôt que de l'exécuter. Pour atteindre une action sensible, le script devrait prendre le contrôle de la page entière et produire une véritable preuve d'identité.
Geste malencontreux. L'invite constitue aussi une pause délibérée avant une action qui modifie qui peut faire quoi dans votre GLPI.
Le principe : les actions les plus dommageables exigent une preuve d'identité fraîche, pas seulement une connexion ancienne.
Ce que vous voyez
Lorsqu'une zone sensible l'exige, GLPI quitte la page où vous étiez et affiche un écran dédié :
Vérifier → si la preuve est correcte, GLPI rejoue automatiquement l'action que vous aviez demandée : vous arrivez sur la page que vous ouvriez, ou votre formulaire est soumis, sans rien avoir à refaire. Si la preuve est incorrecte, un message Échec de l'authentification s'affiche et vous pouvez réessayer.
Annuler → vous revenez à la page d'origine, et rien ne se passe. Annuler est toujours sans risque.
Tout ce que vous aviez saisi dans le formulaire est conservé pendant ce détour : une invite inattendue ne vous fait jamais perdre votre saisie.
Comment votre identité est vérifiée
L'invite ne propose pas de choix : GLPI sélectionne la méthode la plus forte disponible sur votre compte.
Un code de votre application d'authentification (2FA)
Vous avez activé l'authentification à deux facteurs. Toujours privilégié.
Votre mot de passe GLPI
Votre compte est un compte GLPI local avec un mot de passe.
Votre mot de passe d'annuaire
Votre compte provient d'un serveur LDAP / Active Directory.
Votre mot de passe CAS
Vous utilisez un serveur CAS pour vous connecter à GLPI (méthode non recommandée)
Votre mot de passe de boite mail
Vous vous connectez grâce un serveur mail imap
Une simple confirmation (« confirmer cette action »)
Aucune méthode plus forte n'est disponible sur votre compte (voir l'avertissement ci-dessous).
Les plugins peuvent ajouter leur propre méthode — par exemple une confirmation via le fournisseur d'identité avec lequel vous vous connectez (SSO). Lorsqu'une telle méthode est installée et s'applique à votre compte, l'invite l'affiche à la place.
Important — comptes qui n'obtiennent qu'une confirmation.
Un compte sans mot de passe local, sans mot de passe d'annuaire, ni 2FA (typiquement un compte SSO pur) ne peut pas réellement être mis à l'épreuve : l'invite ne demande alors qu'un clic de confirmation. La pause délibérée est conservée, mais ce n'est pas une vérification d'identité. Activer l'authentification à deux facteurs sur de tels comptes — en particulier les comptes administrateurs — restaure la protection.
Durée de validité
La fenêtre s'ouvre quand une vérification réussit, et dure 15 minutes.
Se connecter n'ouvre pas cette fenêtre : la première action sensible d'une session déclenche toujours l'invite.
Elle n'est pas prolongée par l'activité. 15 minutes après la vérification réussie, l'action sensible suivante redemande une vérification — même si vous n'avez jamais cessé de travailler.
La fenêtre est liée à votre session : se déconnecter la referme.
La durée est fixe dans cette version et ne peut pas être configurée. (à confirmer : si elle est destinée à devenir une option de configuration)
Où cela s'applique
La ré-authentification est requise sur les zones ci-dessous. Dans la plupart des cas, la simple lecture suffit à déclencher l'invite, pas seulement l'écriture.
Utilisateurs, droits, organisation
Utilisateurs (y compris création, import depuis une source externe, modification des données d'authentification)
Emprunt d'identité d'un autre utilisateur
Profils, et attribution de profils aux utilisateurs (habilitations)
Groupes, et appartenances aux groupes
Authentification et sécurité
Annuaires LDAP
Serveurs de messagerie (authentification IMAP)
Clients OAuth
Changement de votre propre mot de passe
Changement de vos propres paramètres d'authentification à deux facteurs
Configuration et système
Configuration générale
Configuration de l'inventaire
Plugins : la liste des plugins et la marketplace, ainsi que les actions d'installation / désinstallation / activation / désactivation
Entrées de l'historique (le journal de qui a fait quoi) et les fichiers de journal système (consultation, téléchargement, vidage, suppression)
Actions massives
Une action massive qui cible l'un des types d'éléments ci-dessus déclenche l'invite une fois, puis s'applique à toute la sélection.
Tout le reste — tickets, parc, base de connaissances, rapports, tableaux de bord… — n'est pas concerné. Un utilisateur qui ne s'approche jamais de l'administration ne voit jamais l'invite.
Administrateurs
Cela peut être désactivé globalement — et ne devrait pas l'être. Définir la constante GLPI_DISABLE_REAUTH dans le fichier de configuration local désactive toutes les invites. Cela abaisse le niveau de sécurité de l'ensemble de l'instance : une session volée accorde alors tout le pouvoir administratif. Tant que cette constante est définie, un avertissement s'affiche sur le tableau de bord des administrateurs. Cette constante est une échappatoire temporaire, dont la suppression est prévue dans une future version 12.x — ne construisez pas de processus reposant dessus.
Recommandations
Activer l'authentification à deux facteurs sur les comptes administrateurs. C'est à la fois la preuve la plus forte lors de l'invite, et la seule véritable pour les comptes sans mot de passe dans GLPI ou dans un annuaire.
Passer en revue les comptes qui n'obtiendraient qu'une confirmation (comptes SSO sans 2FA), en particulier ceux détenant des droits de configuration ou de gestion des utilisateurs.
Ne pas confondre la ré-authentification avec les droits. Elle n'accorde jamais rien : une action déjà interdite par un profil reste interdite. Elle ajoute seulement une condition en plus des droits existants.
Notes de support
La vérification LDAP échoue de manière sécurisée (« fail closed ») : une panne d'annuaire bloque les actions sensibles au lieu de les laisser passer. Cela peut aussi se vérifier avec l'authentification CAS et via un serveur mails.
Les plugins peuvent fournir leur propre méthode de vérification ; consultez la documentation du plugin pour savoir ce que son invite demande.
Ce que ce mécanisme ne couvre pas
Il ne protège pas contre un mot de passe compromis ou un authentificateur compromis : il rend seulement une session sans surveillance ou volée beaucoup moins exploitable.
Face à un script injecté, il relève la barre sans fermer complètement la porte : un tel script ne peut pas franchir l'invite par lui-même, mais il peut agir pendant une fenêtre que vous avez déjà ouverte, et il pourrait tenter d'imiter l'invite pour capturer ce que vous saisissez. La ré-authentification est une seconde ligne de défense, pas un substitut à la correction de la faille d'injection.
Elle ne consigne pas de piste d'audit spécifique des invites elles-mêmes. (à confirmer)
Elle s'applique à l'interface web, pas à l'API, à la ligne de commande, ni aux agents d'inventaire.
Mis à jour