Como autenticar usando REMOTE_USER

This document describes how to make use of external authentication sources (where the web server sets the REMOTE_USER environment variable) 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 sets the REMOTE_USER environment variable for use in the underlying application. In Django, REMOTE_USER is made available in the request.META attribute. 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ção

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",
]

Com esta configuração, o :class:`~django.contrib.auth.middleware.RemoteUserMiddleware irá detectar o __username__ em request.META['REMOTE_USER'] e irá autenticar e automaticamente logar aquele usuário usando o 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.

Nota

Um vez que RemoteUserBackend herda de ModelBackend, você ainda terá todos as mesmas permissões de verificação que estão implementadas em ModelBackend.

Usuários com is_active=False não serão permitidos a fazer a autenticação. Use AllowAllUsersRemoteUserBackend se você quiser permití-los.

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",
    "...",
]

Aviso

Tenha muito cuidado se usar a subclasse RemoteUserMiddleware com um cabeçalho HTTP customizado. Tenha certeza que o servidor de front-end sempre defina ou retire o cabeçalho baseado nos checks de autenticação apropriados, nunca permitindo que um usuário submeta um falso (ou falsificado) valor no cabeçalho. Já que os cabeçalhos HTTP X-Auth-User e o X-Auth_User (por exemplo) são ambos normalizados para a chave HTTP_X_AUTH_USER no request.META, tem que ser verificado que o seu servidor web não aceita um cabeçalho falsificado usando “underscores” no lugar de traços.

Este alerta não se aplica ao RemoteUserMiddleware na sua configuração default header = 'REMOTE_USER', já que uma chave que não inicie com HTTP_ em request.META só pode ser setada pelo servidor WSGI, e não diretamente do cabeçalho da requisição HTTP

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.

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.