Autres méthodes d'authentification externe

L'intégration de GLPI et des sources d'authentification au-delà des méthodes internes, LDAP et IMAP est configurée depuis le menu Configuration > Authentification > Autres méthodes d'authentification.

Central Authentication Service (CAS)

La configuration d'un serveur CAS se compose de l'adresse du serveur et de son port (443 par défaut). Un répertoire de base peut être spécifié si nécessaire. Le paramètre d'adresse web de retour vous permet de rediriger l'utilisateur vers une page spécifique après sa déconnexion de GLPI.

Une fois l'authentification CAS activée, chaque authentification est automatiquement redirigée vers le serveur CAS. Afin de vous connecter à un compte interne ou à un compte authentifié via une autre méthode, vous devez ajouter ?noAUTO=1 à l'URL de connexion.

Les extensions php-curl ou php-dom doivent être activées pour que l'authentification CAS fonctionne.

Certificat x509

L'Attribut email pour l'authentification x509 indique à GLPI de consulter la valeur de cet attribut dans la variable de requête HTTP SSL_CLIENT_S_DN passée par le système d'authentification.

Il est possible de restreindre les valeurs acceptées pour les champs O, OR et CN du certificat client. Afin de spécifier plusieurs valeurs pour chaque champ, vous pouvez séparer chaque valeur par le symbole $.

Autres authentifications automatiques

GLPI peut s'appuyer sur d'autres systèmes externes pour authentifier les utilisateurs, tels que :

• Authentification Apache basique

• Authentification de domaine Windows

• Authentification provenant d'un serveur d'authentification comme LemonLDAP::NG, Shibboleth, etc.

Lorsque l'utilisateur souhaite accéder à GLPI, celui-ci vérifie la présence d'une variable dans les en-têtes HTTP stockant le login/nom d'utilisateur. Si la variable est présente, l'authentification est autorisée. Nous pouvons mapper les données transmises par le système d'authentification avec les champs du compte utilisateur de GLPI (nom, prénom, email, langue...). Pour finir, les contrôles d'autorisations sont effectués. Une option permet de supprimer le domaine du login de l'utilisateur (Ex : [email protected] > testuser).

La liste des noms possibles pour les en-têtes est configurable, bien que les plus courants soient déjà fournis par GLPI. Voir Configuration des en-têtes.

Champ de stockage de l'identifiant dans la requête HTTP

Authentification SSO dans GLPI via un serveur web

Dans une architecture SSO (Single Sign-On) via le serveur web, ce n’est pas GLPI qui effectue la vérification de l’identité, mais le serveur web en amont.

Exemple : si vous utilisez l’authentification Windows (Kerberos/NTLM) avec Apache et le module mod_auth_gssapi, c’est Apache qui dialogue directement avec le contrôleur de domaine Active Directory.

Une fois l’utilisateur authentifié (par exemple, "Jean Dupont"), Apache transmet cette information à GLPI via les en-têtes HTTP. GLPI se contente alors de récupérer l’identifiant de l’utilisateur sans gérer l’authentification elle-même.

Variables d’authentification utilisées par GLPI

GLPI peut récupérer l’identifiant utilisateur depuis différentes variables, selon la configuration du serveur web, le type de SSO, ou le proxy utilisé. Voici les principales :

1. HTTP_AUTH_USER

• Origine : Authentification HTTP standard (Basic).

• Description : Variante de PHP_AUTH_USER. Cette variable est souvent générée par des serveurs web configurés en mode CGI ou par certains modules tiers injectant directement l’identifiant dans les en-têtes HTTP.

2. REMOTE_USER

• Origine : Standard de l’industrie (Apache, IIS, Nginx).

• Description : C’est la variable la plus utilisée et la plus sécurisée pour un SSO. Elle est remplie par le serveur web après une authentification réussie (Kerberos, NTLM ou LDAP).

• Recommandation : Pour l’authentification Windows intégrée, utilisez quasi systématiquement REMOTE_USER.

3. PHP_AUTH_USER

• Origine : Authentification "Basic" gérée nativement par PHP.

• Description : Contient le nom d’utilisateur lorsque le navigateur affiche une fenêtre de connexion standard. PHP décode automatiquement l’en-tête Authorization envoyé par le navigateur pour remplir cette variable.

4. USERNAME

• Origine : Environnement système (souvent Windows/IIS).

• Description : Cette variable provient directement de l’environnement système. Moins courante dans un SSO web moderne, elle peut être utilisée si PHP tourne dans un contexte où la session utilisateur du système est transmise au processus PHP.

5. REDIRECT_REMOTE_USER

• Origine : Serveur Apache avec mod_rewrite.

• Description : Variable technique de secours. Lors d’une redirection interne via .htaccess, Apache préfixe parfois REMOTE_USER avec REDIRECT_.

• Cas d’usage : Si l’authentification fonctionne sur la page d’accueil mais pas sur certaines sous-pages, utilisez cette variable.

6. HTTP_REMOTE_USER

• Origine : Reverse proxy ou Load Balancer (Nginx, F5, Citrix…).

• Description : Utilisée lorsque l’équipement frontal effectue l’authentification à la place de GLPI et transmet le login via un en-tête HTTP.

• Remarque : Le préfixe HTTP_ indique que la valeur transite sur le réseau ; elle est donc moins sécurisée qu’une variable système locale.