Comment authentifier avec REMOTE_USER

Ce document présente la procédure pour utiliser des sources d’authentification externes (pour lesquelles le serveur Web définit la variable d’environnement REMOTE_USER) dans vos applications Django. Ce type de solution d’authentification est typique des sites intranet, avec des solutions d’authentification centralisée comme IIS et Integrated Windows Authentication ou Apache et mod_authnz_ldap, CAS, WebAuth, mod_auth_sspi, etc.

Lorsque le serveur Web se charge de l’authentification, il définit généralement la variable d’environnement REMOTE_USER à destination de l’application sous-jacente. Dans Django, REMOTE_USER est accessible par l’attribut request.META. Django peut être configuré pour exploiter la valeur REMOTE_USER en utilisant les classes RemoteUserMiddleware, PersistentRemoteUserMiddleware et RemoteUserBackend qui se trouvent dans 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.

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. In particular, ASGI deployments cannot be exposed directly to the internet (that is, without a reverse proxy) when using this middleware.

Since the HTTP headers X-Auth-User and X-Auth_User (for example) both normalize to the HTTP_X_AUTH_USER key in request.META, you must also check that your web server doesn’t allow a spoofed header using underscores in place of dashes.

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 does apply by default on ASGI, because in the async path, the middleware prepends HTTP_ to the defined header name before looking it up in request.META.

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.