Come autenticarsi usando REMOTE_USER

This document describes how to make use of external authentication sources 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, WebAuth, mod_auth_sspi, etc.

When the web server takes care of authentication it typically provides the authenticated user as REMOTE_USER. In Django, this value is made available in request.META (as REMOTE_USER when supplied as an environment variable, as in WSGI, or HTTP_REMOTE_USER when supplied via an HTTP header, as in ASGI). 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.

Configurazione

In primo luogo, devi aggiungere la classe django.contrib.auth.middleware.RemoteUserMiddleware nel file settings.py MIDDLEWARE posizionato dopo la classe django.contrib.auth.middleware.AuthenticationMiddleware:

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

Poi, devi sostituire ModelBackend con RemoteUserBackend nella impostazione di AUTHENTICATION_BACKENDS

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

With this setup, RemoteUserMiddleware will detect the username in request.META['REMOTE_USER'] (or request.META['HTTP_REMOTE_USER'] under ASGI) and will authenticate and auto-login that user using the RemoteUserBackend.

Sii cosciente che questa particolare configurazione disabilita l’autenticazione con il ModelBackend di default. Questo significa che se il valore di REMOTE_USER non è impostato, l’utente non potrà fare log in, anche utilizzando l’interfaccia di amministrazione di Django. Aggiungendo 'django.contrib.auth.backends.ModelBackend' all’elenco AUTHENTICATION_BACKENDS si userà ModelBackend come ripiego se è assente REMOTE_USER , risolvendo questo inconveniente.

La gestione utenti di Django, come le view in contrib.admin e il comando di gestione createsuperuser , non si integrano con gli utenti remoti. Queste interfacce lavorano con gli utenti memorizzati nel database, indipendentemente dagli AUTHENTICATION_BACKENDS.

Nota

Poiché il RemoteUserBackend eredita da ModelBackend, avrai ancora tutto il controllo sui permessi che è implementato in ModelBackend.

Gli utenti con l’attributo is_active=False non avranno il permesso di autenticarsi. Usa AllowAllUsersRemoteUserBackend se vuoi permettere l’autenticazione.

If your authentication mechanism uses a custom HTTP header and not REMOTE_USER, you can subclass RemoteUserMiddleware and set the header attribute to the desired request.META key. For example:

mysite/middleware.py

 from django.contrib.auth.middleware import RemoteUserMiddleware


 class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):
     header = "HTTP_AUTHUSER"

This custom middleware is then used in the MIDDLEWARE setting instead of django.contrib.auth.middleware.RemoteUserMiddleware:

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

Avvertimento

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.

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 applies under ASGI in all configurations, because there is no equivalent for a WSGI server’s ability to place a trusted value in the environ. ASGI deployments must use a reverse proxy as described above when using this middleware.

Se hai necessità di più controllo, puoi creare il tuo backend di autenticazione che eredita da RemoteUserBackend e sostituisce uno o più dei suoi attributi e metodi.

Usare REMOTE_USER solo sulle pagine di login

Il RemoteUserMiddleware presuppone che l’intestazione HTTP REMOTE_USER sia presente in tutte le richieste che necessitano di autenticazione. Può essere quindi usato quando si ha a che fare con il Basic HTTP Auth con htpasswd o altri semplici meccanismi; quando invece si usa Negotiate (GSSAPI/Kerberos) o un altro metodo di autenticazione che richiede maggiori risorse, l’autenticazione nel server HTTP di front-end è normalmente utilizzata in ambienti ristretti con pochi URL di accesso, e dopo un’autenticazione riuscita, si suppone che l’applicazione mantenga autonomamente la sessione autenticata.

PersistentRemoteUserMiddleware fornisce supporto per questo caso d’uso. Mantiene la sessione autenticata fino ad un logout esplicito dell’utente. La classe può essere usata in sostituzione in cascata di RemoteUserMiddleware nella documentazione di cui sopra.