How to authenticate using REMOTE_USER
¶
This document describes how to make use of external authentication sources
(where the web server sets the REMOTE_USER
environment variable) 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, Cosign,
WebAuth, mod_auth_sspi, etc.
When the web server takes care of authentication it typically sets the
REMOTE_USER
environment variable for use in the underlying application. In
Django, REMOTE_USER
is made available in the request.META
attribute. 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
.
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.
Si su mecanismo de autenticación usa una cabecera HTTP personalizada y no REMOTE_USER
, puede crear una clase hija de RemoteUserMiddleware
y configurar el atributo header
con la llave de request.META
deseada. Por ejemplo:
from django.contrib.auth.middleware import RemoteUserMiddleware
class CustomHeaderMiddleware(RemoteUserMiddleware):
header = 'HTTP_AUTHUSER'
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¶
The RemoteUserMiddleware
authentication middleware assumes that the HTTP
request header REMOTE_USER
is present with all authenticated requests. That
might be expected and practical when Basic HTTP Auth with htpasswd
or
similar mechanisms are used, but with Negotiate (GSSAPI/Kerberos) or other
resource intensive authentication methods, the authentication in the front-end
HTTP server is usually only set up for one or a few login URLs, and after
successful authentication, the application is supposed to maintain the
authenticated session itself.
PersistentRemoteUserMiddleware
provides support for this use case. It will maintain the authenticated session
until explicit logout by the user. The class can be used as a drop-in
replacement of RemoteUserMiddleware
in the documentation above.