Autenticação usando REMOTE_USER
¶
Este documento descreve como usar fontes externas de autenticação (quando o servidor define a variável de ambiente REMOTE_USER
) em suas aplicações Django. Este tipo de solução de autenticação é geralmente usado em sites de intranet, com soluções single sign-on como o IIS e autenticação Integrada do Windows ou Apache e mod_authnz_ldap, CAS, Cosign, WebAuth, mod_auth_sspi, etc.
Quando o servidor Web se encarrega da autenticação ele normalmente define a variável de ambiente REMOTE_USER
para uso na aplicação que está sendo executada. No Django, REMOTE_USER
é disponibilizado no atributo request.META
. O Django pode ser configurado para fazer uso do REMOTE_USER
usando as classes django.contrib.auth.middleware.RemoteUserMiddleware
e RemoteUserBackend
encontrados em:mod: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.
Se o seu mecanismo de autenticação utilizar um cabeçalho HTTP costumizado e não o REMOTE_USER`, você pode utilizar a subclass ``RemoteUserMiddleware
e definir o atributo header
para atribuir a chave request.META
. Por exemplo:
from django.contrib.auth.middleware import RemoteUserMiddleware
class CustomHeaderMiddleware(RemoteUserMiddleware):
header = 'HTTP_AUTHUSER'
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, más 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.