Authentification 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, Cosign, 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 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_CLASSES après la valeur django.contrib.auth.middleware.AuthenticationMiddleware :

MIDDLEWARE_CLASSES = (
    '...',
    '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.

Note

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

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 :

from django.contrib.auth.middleware import RemoteUserMiddleware

class CustomHeaderMiddleware(RemoteUserMiddleware):
    header = 'HTTP_AUTHUSER'

Avertissement

Be very careful if using a RemoteUserMiddleware subclass with a custom HTTP header. You must be sure that your front-end web server 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. 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.

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.

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.