# Documentation Django 6.0.7

# Comment authentifier avec `REMOTE_USER`

This document describes how to make use of external authentication sources 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 provides the authenticated user as `REMOTE_USER`. In Django, this value is made available in `request.META` (as `REMOTE_USER` when supplied as an environment variable, as in WSGI, or `HTTP_REMOTE_USER` when supplied via an HTTP header, as in ASGI). 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",
    ]

With this setup, `RemoteUserMiddleware` will detect the username in `request.META['REMOTE_USER']` (or `request.META['HTTP_REMOTE_USER']` under ASGI) and will authenticate and auto-login that user using the `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.

Si votre mécanisme d’authentification utilise un en-tête HTTP personnalisé à la place de `REMOTE_USER`, vous pouvez créer une sous-classe de `RemoteUserMiddleware` et définir l’attribut `header` à la clé de `request.META` désirée. Par exemple :

`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

`RemoteUserMiddleware` must not be deployed in configurations where a client can supply the header. You must be sure that your web server or reverse proxy always sets or strips that header based on the appropriate authentication checks, never permitting an end user to submit a fake (or « spoofed ») header value.

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 `request.META`, vous devez aussi contrôler que votre serveur web n’autorise pas d’en-tête fabriqué qui utiliserait des soulignements à la place des tirets.

Under WSGI, this warning doesn’t apply to `RemoteUserMiddleware` in its default configuration with `header = "REMOTE_USER"`, since a key that doesn’t start with `HTTP_` in `request.META` can only be set by your WSGI server, not directly from an HTTP request header.

This warning applies under ASGI in all configurations, because there is no equivalent for a WSGI server’s ability to place a trusted value in the environ. ASGI deployments must use a reverse proxy as described above when using this middleware.

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.