# 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) <a href="#auth_cas" id="auth_cas"></a>

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.

{% hint style="warning" %}
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.
{% endhint %}

{% hint style="info" %}
Les extensions `php-curl` ou `php-dom` doivent être activées pour que l'authentification CAS fonctionne.
{% endhint %}

## Certificat x509 <a href="#auth_x509" id="auth_x509"></a>

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 <a href="#auth_other" id="auth_other"></a>

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 : <testuser@example.com> > testuser).

{% hint style="info" %}
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](/documentation/fr/modules/configuration/dropdowns/index.md).
{% endhint %}

### 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.glpi-project.org/documentation/fr/modules/configuration/authentication/other.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.