REMOTE_USERLink to this heading#This document describes how to make use of external authentication sources in\nyour Django applications. This type of authentication solution is typically\nseen on intranet sites, with single sign-on solutions such as IIS and\nIntegrated Windows Authentication or Apache and mod_authnz_ldap, CAS,\nWebAuth, mod_auth_sspi, etc.
\nWhen the web server takes care of authentication it typically provides the\nauthenticated user as REMOTE_USER. In Django, this value is made available\nin request.META (as REMOTE_USER when\nsupplied as an environment variable, as in WSGI, or HTTP_REMOTE_USER when\nsupplied via an HTTP header, as in ASGI). Django can be configured to make use\nof the REMOTE_USER value using the RemoteUserMiddleware or\nPersistentRemoteUserMiddleware, and\nRemoteUserBackend classes found in\ndjango.contrib.auth.
First, you must add the\ndjango.contrib.auth.middleware.RemoteUserMiddleware to the\nMIDDLEWARE setting after the\ndjango.contrib.auth.middleware.AuthenticationMiddleware:
MIDDLEWARE = [\n "...",\n "django.contrib.auth.middleware.AuthenticationMiddleware",\n "django.contrib.auth.middleware.RemoteUserMiddleware",\n "...",\n]\nNext, you must replace the ModelBackend\nwith RemoteUserBackend in the\nAUTHENTICATION_BACKENDS setting:
AUTHENTICATION_BACKENDS = [\n "django.contrib.auth.backends.RemoteUserBackend",\n]\nWith this setup, RemoteUserMiddleware will detect the username in\nrequest.META['REMOTE_USER'] (or request.META['HTTP_REMOTE_USER'] under\nASGI) and will authenticate and auto-login that user\nusing the RemoteUserBackend.
Be aware that this particular setup disables authentication with the default\nModelBackend. This means that if the REMOTE_USER value is not set\nthen the user is unable to log in, even using Django’s admin interface.\nAdding 'django.contrib.auth.backends.ModelBackend' to the\nAUTHENTICATION_BACKENDS list will use ModelBackend as a fallback\nif REMOTE_USER is absent, which will solve these issues.
Django’s user management, such as the views in contrib.admin and\nthe createsuperuser management command, doesn’t integrate with\nremote users. These interfaces work with users stored in the database\nregardless of AUTHENTICATION_BACKENDS.
If your authentication mechanism uses a custom HTTP header and not\nREMOTE_USER, you can subclass RemoteUserMiddleware and set the\nheader attribute to the desired request.META key. For example:
mysite/middleware.py from django.contrib.auth.middleware import RemoteUserMiddleware\n\n\n class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):\n header = "HTTP_AUTHUSER"\nThis custom middleware is then used in the MIDDLEWARE setting\ninstead of django.contrib.auth.middleware.RemoteUserMiddleware:
MIDDLEWARE = [\n "...",\n "django.contrib.auth.middleware.AuthenticationMiddleware",\n "mysite.middleware.CustomHeaderRemoteUserMiddleware",\n "...",\n]\nIf you need more control, you can create your own authentication backend\nthat inherits from RemoteUserBackend and\noverride one or more of its attributes and methods.
REMOTE_USER on login pages onlyLink 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.