Hur man autentiserar med hjälp av REMOTE_USER

Detta dokument beskriver hur du använder externa autentiseringskällor (där webbservern ställer in miljövariabeln REMOTE_USER) i dina Django-applikationer. Denna typ av autentiseringslösning förekommer vanligtvis på intranätssajter, med enkel inloggning (single sign-on) som IIS och Integrated Windows Authentication eller Apache och mod_authnz_ldap, CAS, WebAuth, mod_auth_sspi, etc.

När webbservern sköter autentiseringen ställer den vanligtvis in miljövariabeln REMOTE_USER för användning i den underliggande applikationen. I Django görs REMOTE_USER tillgänglig i attributet request.META. Django kan konfigureras för att använda värdet REMOTE_USER med hjälp av RemoteUserMiddleware eller PersistentRemoteUserMiddleware och klasserna RemoteUserBackend som finns i django.contrib.auth.

Konfiguration

Först måste du lägga till django.contrib.auth.middleware.RemoteUserMiddleware i inställningen MIDDLEWARE efter django.contrib.auth.middleware.AuthenticationMiddleware:

MIDDLEWARE = [
    "...",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.auth.middleware.RemoteUserMiddleware",
    "...",
]

Därefter måste du ersätta ModelBackend med RemoteUserBackend i inställningen AUTHENTICATION_BACKENDS:

AUTHENTICATION_BACKENDS = [
    "django.contrib.auth.backends.RemoteUserBackend",
]

Med denna inställning kommer RemoteUserMiddleware att upptäcka användarnamnet i request.META['REMOTE_USER'] och autentisera och automatiskt logga in den användaren med hjälp av RemoteUserBackend.

Var medveten om att just denna inställning inaktiverar autentisering med standard ModelBackend. Detta innebär att om värdet REMOTE_USER inte är inställt kan användaren inte logga in, inte ens med hjälp av Djangos administratörsgränssnitt. Genom att lägga till 'django.contrib.auth.backends.ModelBackend' i listan AUTHENTICATION_BACKENDS kommer ModelBackend att användas som reserv om REMOTE_USER saknas, vilket kommer att lösa dessa problem.

Djangos användarhantering, till exempel vyerna i contrib.admin och kommandot createsuperuser, integreras inte med fjärranvändare. Dessa gränssnitt fungerar med användare som är lagrade i databasen oavsett AUTHENTICATION_BACKENDS.

Observera

Eftersom RemoteUserBackend ärver från ModelBackend kommer du fortfarande att ha samma behörighetskontroll som implementeras i ModelBackend.

Användare med is_active=False tillåts inte att autentisera sig. Använd AllowAllUsersRemoteUserBackend om du vill tillåta dem att göra det.

Om din autentiseringsmekanism använder en anpassad HTTP-header och inte REMOTE_USER, kan du skapa en underklass till RemoteUserMiddleware och ställa in attributet header till önskad request.META-nyckel. Till exempel:

mysite/middleware.py

 from django.contrib.auth.middleware import RemoteUserMiddleware


 class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):
     header = "HTTP_AUTHUSER"

Denna anpassade middleware används sedan i inställningen MIDDLEWARE istället för django.contrib.auth.middleware.RemoteUserMiddleware:

MIDDLEWARE = [
    "...",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "mysite.middleware.CustomHeaderRemoteUserMiddleware",
    "...",
]

Varning

RemoteUserMiddleware must not be deployed in configurations where a client can supply the header. You must be sure that your web server or reverse proxy always sets or strips that header based on the appropriate authentication checks, never permitting an end user to submit a fake (or ”spoofed”) header value. In particular, ASGI deployments cannot be exposed directly to the internet (that is, without a reverse proxy) when using this middleware.

Since the HTTP headers X-Auth-User and X-Auth_User (for example) both normalize to the HTTP_X_AUTH_USER key in request.META, you must also check that your web server doesn’t allow a spoofed header using underscores in place of dashes.

Under WSGI, this warning doesn’t apply to RemoteUserMiddleware in its default configuration with header = "REMOTE_USER", since a key that doesn’t start with HTTP_ in request.META can only be set by your WSGI server, not directly from an HTTP request header. This warning does apply by default on ASGI, because in the async path, the middleware prepends HTTP_ to the defined header name before looking it up in request.META.

Om du behöver mer kontroll kan du skapa din egen autentiseringsbackend som ärver från RemoteUserBackend och åsidosätta ett eller flera av dess attribut och metoder.

Använda REMOTE_USER endast på inloggningssidor

Autentiseringsmellanvaran RemoteUserMiddleware förutsätter att HTTP-förfrågningshuvudet REMOTE_USER finns med i alla autentiserade förfrågningar. Detta kan vara förväntat och praktiskt när grundläggande HTTP-autentisering med htpasswd eller liknande mekanismer används, men med Negotiate (GSSAPI/Kerberos) eller andra resurskrävande autentiseringsmetoder konfigureras autentiseringen i HTTP-frontservern vanligtvis bara för en eller ett fåtal inloggningsadresser, och efter en lyckad autentisering är det meningen att applikationen själv ska upprätthålla den autentiserade sessionen.

PersistentRemoteUserMiddleware ger stöd för detta användningsfall. Den kommer att behålla den autentiserade sessionen tills användaren uttryckligen loggar ut. Klassen kan användas som en drop-in-ersättning av RemoteUserMiddleware i dokumentationen ovan.