Como autenticar usando REMOTE_USERLink para este cabeçalho
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.
ConfiguraçãoLink para este cabeçalho
Primeiro você deve adicionar django.contrib.auth.middleware.RemoteUserMiddleware no MIDDLEWARE definindo depois do django.contrib.auth.middleware.AuthenticationMiddleware:
MIDDLEWARE = [
"...",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.contrib.auth.middleware.RemoteUserMiddleware",
"...",
]
Depois você deve substituir a ModelBackend por RemoteUserBackend na configuração 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.
Esteja ciente de que essa definição em particular desabilita a autenticação com o padrão ModelBackend. Isso significa que se o valor de REMOTE_USER não estiver definido o usuário não conseguirá logar-se, mesmo utilizando a inteface do Django admin. Adicionando django.contrib.auth.backends.ModelBackend à lista AUTHENTICATION_BACKENDS ele será utilizado como um substituto se “REMOTE_USER” estiver ausente, e esse problema não acontecerá.
O gerenciamento de usuários do Django, bem como as views em contrib.admin, e o comando de gerenciamento createsuperuser, não fazem integração com usuários remotos. Esta interface trabalha com usuários armazenados no banco de dados independente do AUTHENTICATION_BACKENDS.
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",
"...",
]
Se você precisa de mais controle, é possível criar seu próprio “backend” de autenticação que herda de RemoteUserBackend e sobrescreve um ou mais de seus atributos e métodos.
Usando REMOTE_USER apenas nas páginas de login.Link para este cabeçalho
O middleware de autenticação RemoteUserMiddleware assume que o cabeçalho REMOTE_USER da requisição HTTP está presente em todas as requisições autenticadas. Isso é esperado e até prático quando usado em uma autenticação HTTP básica com htpasswd ou um outro mecanismo simples, mas com uma requisição Negotiate (GSSAPI/Kerberos) ou outro método de autenticação de fontes intensivas, a autenticação no servidor HTTP de front-end é comumente configurada para uma ou algumas poucas URLS de login, e depois de uma autenticação bem sucedida, é esperado que a aplicação mantenha a sessão de autenticação por conta própria.
A classe PersistentRemoteUserMiddleware provê suporte para este caso de uso. Ele manterá a sessão de autenticação até o logout explícito do usuário. A classe pode ser usada como um substituto constante para RemoteUserMiddleware na documentação acima.