# Documentation Django 5.2.8

# Comment authentifier avec `REMOTE_USER`

This document describes how to make use of external authentication sources (where the web server sets the `REMOTE_USER` environment variable) in your Django applications. This type of authentication solution is typically seen on intranet sites, with single sign-on solutions such as IIS and Integrated Windows Authentication or Apache and mod_authnz_ldap, CAS, WebAuth, mod_auth_sspi, etc.

When the web server takes care of authentication it typically sets the `REMOTE_USER` environment variable for use in the underlying application. In Django, `REMOTE_USER` is made available in the `request.META` attribute. Django can be configured to make use of the `REMOTE_USER` value using the `RemoteUserMiddleware` or `PersistentRemoteUserMiddleware`, and `RemoteUserBackend` classes found in `django.contrib.auth`.

## Configuration

Vous devez tout d’abord ajouter `django.contrib.auth.middleware.RemoteUserMiddleware` au réglage `MIDDLEWARE` après la valeur `django.contrib.auth.middleware.AuthenticationMiddleware` :

    MIDDLEWARE = [
        "...",
        "django.contrib.auth.middleware.AuthenticationMiddleware",
        "django.contrib.auth.middleware.RemoteUserMiddleware",
        "...",
    ]

Puis, vous devez remplacez `ModelBackend` par `RemoteUserBackend` dans le réglage `AUTHENTICATION_BACKENDS` :

    AUTHENTICATION_BACKENDS = [
        "django.contrib.auth.backends.RemoteUserBackend",
    ]

Avec cette configuration, `RemoteUserMiddleware` va détecter le nom d’utilisateur dans `request.META['REMOTE_USER']` et va authentifier et connecter automatiquement cet utilisateur à l’aide de `RemoteUserBackend`.

Soyez conscient que cette configuration particulière désactive l’authentification avec le `ModelBackend` par défaut. Cela signifie que si la valeur de `REMOTE_USER` n’est pas configurée, l’utilisateur ne parviendra pas à se connecter, même en utilisant l’interface d’administration de Django. Ajouter `'django.contrib.auth.backends.ModelBackend'` à la liste des `AUTHENTICATION_BACKENDS` utilisera `ModelBackend` comme solution de repli si `REMOTE_USER` est absent, ce qui permettra de résoudre ces problèmes.

La gestion des utilisateurs de Django, tels que les vue de `contrib.admin` et la commande de gestion `createsuperuser`, ne s’intègrent pas avec des utilisateurs distants. Ces interfaces travaillent avec les utilisateurs stockés dans la base de données indépendamment de `` AUTHENTICATION_BACKENDS``.

Note

Comme `RemoteUserBackend` hérite de `ModelBackend`, le contrôle des permissions implémenté dans `ModelBackend` est toujours disponible.

Les utilisateurs avec `is_active=False` ne seront pas autorisés à s’authentifier. Utilisez `AllowAllUsersRemoteUserBackend` si vous voulez les autoriser à se connecter.

If your authentication mechanism uses a custom HTTP header and not `REMOTE_USER`, you can subclass `RemoteUserMiddleware` and set the `header` attribute to the desired `request.META` key. For example:

`monsite/middleware.py`

     from django.contrib.auth.middleware import RemoteUserMiddleware

     class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):
         header = "HTTP_AUTHUSER"

Cet intergiciel personnalisé est alors utilisé dans le réglage `MIDDLEWARE` à la place de `django.contrib.auth.middleware.RemoteUserMiddleware`:

    MIDDLEWARE = [
        "...",
        "django.contrib.auth.middleware.AuthenticationMiddleware",
        "mysite.middleware.CustomHeaderRemoteUserMiddleware",
        "...",
    ]

Avertissement

Soyez très prudent si vous utilisez une sous-classe de `RemoteUserMiddleware` avec un en-tête HTTP personnalisé. Vous devez être certain que le serveur Web frontal définit ou ajuste toujours cet en-tête sur la base des contrôles d’authentification appropriés, et ne permet à personne d’envoyer une valeur d’en-tête trafiquée. Comme les en-têtes HTTP `X-Auth-User` et `X-Auth_User` (par exemple) sont tous deux normalisés en `HTTP_X_AUTH_USER` dans le dictionnaire `request.META`, vous devez aussi contrôler que votre serveur Web n’autorise pas les en-têtes trafiqués qui utilisent des soulignements à la place des tirets.

Cet avertissement ne s’applique pas à `RemoteUserMiddleware` dans sa configuration par défaut avec `header = 'REMOTE_USER'`, car une clé qui ne commence pas par `HTTP_` dans `request.META` ne peut être définie que par le serveur WSGI, et pas directement à partir d’un en-tête de requête HTTP.

Si vous avez besoin de plus de maîtrise, vous pouvez créer votre propre moteur d’authentification héritant de `RemoteUserBackend` et surcharger un ou plusieurs de ses attributs et méthodes.

## Utilisation de `REMOTE_USER` uniquement pour les pages de connexion

L’intergiciel d’authentification `RemoteUserMiddleware` part du principe que l’en-tête de requête HTTP `REMOTE_USER` est présent pour toutes les requêtes authentifiées. C’est en général le cas lorsqu’un mécanisme du genre Basic HTTP Auth avec `htpasswd` est utilisé, mais avec des méthodes d’authentification comme Negotiate (GSSAPI/Kerberos) ou autres méthodes gourmandes en ressources, l’authentification au niveau du serveur HTTP frontal n’est habituellement configurée que pour une ou quelques URL de connexion ; après une authentification réussie, l’application est censé maintenir elle-même la session authentifiée.

`PersistentRemoteUserMiddleware` prend en charge ce cas d’utilisation. Il maintient la session authentifiée jusqu’à une déconnexion explicite par l’utilisateur. Cette classe peut être utilisée en remplacement de `RemoteUserMiddleware` dans la documentation ci-dessus sans autre modification.