REMOTE_USERLink to this heading#Este documento describe como hacer uso de los recursos de autenticación remota (donde el servidor web define la variable de entorno REMOTE_USER) en tu aplicaciones Django. Este tipo de solución de autenticación es típicamente vista en sitios de intranet con soluciones simples de ingreso como IIS con Integrated Windows Authentication o apache con mod_authnz_ldap, CAS, Cosign, WebAuth, mod_auth_sspi, etc.
Cuando el servidor web se ocupa de la autenticación, típicamente define la variable de ambiente REMOTE_USER para el uso subyacente en la aplicación. En Django, REMOTE_USER está disponible en el atributo request.META. Django puede ser configurado para hacer uso del valor de REMOTE_USER usando el RemoteUserMiddleware o el PersistentRemoteUserMiddleware y las clases RemoteUserBackend encontradas en django.contrib.auth.
Primero debes agregar la clase django.contrib.auth.middleware.RemoteUserMiddleware a la configuración de MIDDLEWARE después de django.contrib.auth.middleware.AuthenticationMiddleware:
MIDDLEWARE = [\n '...',\n 'django.contrib.auth.middleware.AuthenticationMiddleware',\n 'django.contrib.auth.middleware.RemoteUserMiddleware',\n '...',\n]\nLuego, debes remplazar la clase ModelBackend por RemoteUserBackend en la configuración AUTHENTICATION_BACKENDS:
AUTHENTICATION_BACKENDS = [\n 'django.contrib.auth.backends.RemoteUserBackend',\n]\nCon 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.
Se conciente 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.
Si tu mecanismo de autenticación usa una cabecera HTTP personalizada y no REMOTE_USER, puedes 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\n\nclass CustomHeaderMiddleware(RemoteUserMiddleware):\n header = 'HTTP_AUTHUSER'\nSi necesitas más control, puedes crear tu propio backend de autenticación que herede de RemoteUserBackend y redefinir uno o más de sus atributos y métodos.
REMOTE_USER en paginas de ingreso solamenteLink to this heading#The RemoteUserMiddleware authentication middleware assumes that the HTTP\nrequest header REMOTE_USER is present with all authenticated requests. That\nmight be expected and practical when Basic HTTP Auth with htpasswd or\nsimilar mechanisms are used, but with Negotiate (GSSAPI/Kerberos) or other\nresource intensive authentication methods, the authentication in the front-end\nHTTP server is usually only set up for one or a few login URLs, and after\nsuccessful authentication, the application is supposed to maintain the\nauthenticated session itself.
PersistentRemoteUserMiddleware\nprovides support for this use case. It will maintain the authenticated session\nuntil explicit logout by the user. The class can be used as a drop-in\nreplacement of RemoteUserMiddleware\nin the documentation above.