Hur man autentiserar med hjälp av REMOTE_USER

Det här dokumentet beskriver hur du använder externa autentiseringskällor i dina Django-applikationer. Den här typen av autentiseringslösning förekommer vanligtvis på intranät med enkel inloggning, som IIS och Integrated Windows Authentication eller Apache och mod_authnz_ldap, CAS, WebAuth, mod_auth_sspi med flera.

När webbservern hanterar autentisering tillhandahåller den vanligtvis den autentiserade användaren som REMOTE_USER. I Django görs värdet tillgängligt i request.META (som REMOTE_USER när det anges som en miljövariabel, som i WSGI, eller HTTP_REMOTE_USER när det anges via en HTTP-rubrik, som i ASGI). Django kan konfigureras för att använda värdet REMOTE_USER med klasserna RemoteUserMiddleware eller PersistentRemoteUserMiddleware och RemoteUserBackend 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 den här konfigurationen upptäcker RemoteUserMiddleware användarnamnet i request.META['REMOTE_USER'] (eller request.META['HTTP_REMOTE_USER'] under ASGI) och autentiserar och loggar automatiskt in användaren med 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 får inte driftsättas i konfigurationer där en klient kan ange rubriken. Du måste säkerställa att webbservern eller den omvända proxyn alltid sätter eller tar bort rubriken utifrån lämpliga autentiseringskontroller och aldrig låter en slutanvändare skicka in ett falskt (eller ”spoofat”) rubrikvärde.

Eftersom HTTP-rubrikerna X-Auth-User och X-Auth_User (till exempel) båda normaliseras till nyckeln HTTP_X_AUTH_USER i request.META, måste du också kontrollera att webbservern inte tillåter en förfalskad rubrik där understreck används i stället för bindestreck.

Under WSGI gäller inte den här varningen för RemoteUserMiddleware i dess standardkonfiguration med header = "REMOTE_USER", eftersom en nyckel i request.META som inte börjar med HTTP_ bara kan sättas av WSGI-servern och inte direkt av en HTTP-rubrik i en begäran.

Varningen gäller under ASGI i alla konfigurationer, eftersom det inte finns någon motsvarighet till en WSGI-servers möjlighet att placera ett betrott värde i miljön. ASGI-driftsättningar måste använda en omvänd proxy enligt beskrivningen ovan när denna middleware används.

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.