Cómo autenticarse usando REMOTE_USER
¶
Este documento describe cómo hacer uso de fuentes de autenticación externas (donde el servidor web establece la variable de entorno REMOTE_USER
) en sus aplicaciones Django. Este tipo de solución de autenticación se suele ver en sitios de intranet, con soluciones de inicio de sesión único como IIS y autenticación integrada de Windows o Apache y mod_authnz_ldap, CAS, `Cosign`_, WebAuth, mod_auth_sspi, etc.
Cuando el servidor web se encarga de la autenticación, normalmente establece la variable de entorno REMOTE_USER
para su uso en la aplicación subyacente. En Django, “”REMOTE_USER”” está disponible en la solicitud atributo request.META
Django se puede configurar para hacer uso del valor REMOTE_USER
usando las clases RemoteUserMiddleware
o PersistentRemoteUserMiddleware
, y RemoteUserBackend
que se encuentran en :mod`”django.contrib.auth`.
Configuración¶
Primero debe agregar la clase django.contrib.auth.middleware.RemoteUserMiddleware
a la configuración de MIDDLEWARE
después de django.contrib.auth.middleware.AuthenticationMiddleware
:
MIDDLEWARE = [
"...",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.contrib.auth.middleware.RemoteUserMiddleware",
"...",
]
Luego, debe remplazar la clase ModelBackend
por RemoteUserBackend
en la configuración AUTHENTICATION_BACKENDS
:
AUTHENTICATION_BACKENDS = [
"django.contrib.auth.backends.RemoteUserBackend",
]
Con esta configuración, RemoteUserMiddleware
detectará el usuario en request.META['REMOTE_USER']
y autenticará e iniciará automáticamente la sesión de usuario usando RemoteUserBackend
.
Sea conciente de que esta configuración particular deshabilita la autenticación por defecto con el ModelBackend
. Esto significa que si el valor del REMOTE_USER
no está definido, entonces el usuario no será capaz de ingresar, incluso usando la interfaz de administración de Django. Agregando 'django.contrib.auth.backends.ModelBackend'
a la lista de AUTHENTICATION_BACKENDS
, servirá como respaldo si REMOTE_USER
no está definido, lo que resolverá estas problemáticas.
El sistema de usuarios de Django, como las vistas en contrib.admin
y el comando de manejo createsuperuser
, no se integran con usuarios remotos. Estas interfaces trabajan con usuarios almacenados en la base de datos independientemente de AUTHENTICATION_BACKENDS
.
Nota
Como RemoteUserBackend
hereda de ModelBackend
, todavía tendrá la misma comprobación de permisos implementada en ModelBackend
.
Usuarios con is_active=False
no serán capaces de autenticarse. Use AllowAllUsersRemoteUserBackend
si quiere permitirles hacerlo.
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:
mysite/middleware.py
¶ from django.contrib.auth.middleware import RemoteUserMiddleware
class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):
header = "HTTP_AUTHUSER"
This custom middleware is then used in the MIDDLEWARE
setting
instead of django.contrib.auth.middleware.RemoteUserMiddleware
:
MIDDLEWARE = [
"...",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"mysite.middleware.CustomHeaderRemoteUserMiddleware",
"...",
]
Advertencia
Sea muy cuidadoso al usar una subclase de RemoteUserMiddleware
con un encabezado HTTP personalizado. Debe asegurarse que su servidor web siempre defina o separe ese encabezado basado en las validaciones apropiadas de autenticación, nunca permitiendo que un usuario final envíe un encabezado falso (o envenenado). Desde que los encabezados HTTP X-Auth-User
y X-Auth_User
(por ejemplo) se normalizan en la llave HTTP_X_AUTH_USER
de request.META
, usted debe verificar que el servidor web no permita encabezados envenenados usando guiones bajos en lugar de guiones.
Esta advertencia no se aplica a RemoteUserMiddleware
en su configuración por omisión con header = 'REMOTE_USER'
, pues las llaves de request.META
que no comiencen con HTTP_
solo pueden ser establecidas por el servidor WSGI, no directamente desde una cabecera de petición HTTP.
Si necesita más control, puedes crear su propio backend de autenticación que herede de RemoteUserBackend
y redefinir uno o más de sus atributos y métodos.
Usando REMOTE_USER
en paginas de ingreso solamente¶
El middleware de autenticación RemoteUserMiddleware
asume que el encabezado de solicitud HTTP REMOTE_USER
está presente con todas las solicitudes autenticadas. Eso podría ser esperado y práctico cuando se utiliza autenticación HTTP básica con htpasswd
o mecanismos similares, pero con Negotiate (GSSAPI/Kerberos) u otros métodos de autenticación intensivos en recursos, la autenticación en el servidor HTTP front-end normalmente solo se configura para una o varias direcciones URL de inicio de sesión, y después de una autenticación correcta, se supone que la aplicación debe mantener la sesión autenticada.
PersistentRemoteUserMiddleware
proporciona soporte para este caso de uso. Mantendrá la sesión autenticada hasta que el usuario cierre la sesión explícitamente. La clase se puede utilizar como un reemplazo directo de RemoteUserMiddleware
en la documentación anterior.