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
, 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.
Dans les anciennes versions, les utilisateurs inactifs n’étaient pas rejetés comme expliqué ci-dessus.
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
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.