How to authenticate using 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, Cosign,
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
.
Конфигурация¶
Во-первых, вы должны добавить django.contrib.auth.middleware.RemoteUserMiddleware
к параметру MIDDLEWARE
после параметра django.contrib.auth.middleware.AuthenticationMiddleware
:
MIDDLEWARE = [
'...',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.RemoteUserMiddleware',
'...',
]
Далее необходимо заменить ModelBackend
на RemoteUserBackend
в параметре AUTHENTICATION_BACKENDS
:
AUTHENTICATION_BACKENDS = [
'django.contrib.auth.backends.RemoteUserBackend',
]
При такой настройке RemoteUserMiddleware
обнаружит имя пользователя в request.META['REMOTE_USER']
и будет аутентифицировать и автологинить этого пользователя с помощью RemoteUserBackend
.
Имейте в виду, что эта конкретная настройка отключает аутентификацию со значением по умолчанию ModelBackend
. Это означает, что если значение REMOTE_USER
не установлено, то пользователь не сможет войти в систему, даже используя интерфейс администратора Django. Добавление 'django.contrib.auth.backends.ModelBackend'
к списку AUTHENTICATION_BACKENDS
будет использовать ModelBackend
в качестве запасного варианта, если REMOTE_USER
отсутствует, что решит эти проблемы.
Управление пользователями в Django, такое как представления в contrib.admin
и команда управления createsuperuser
, не интегрируется с удаленными пользователями. Эти интерфейсы работают с пользователями, хранящимися в базе данных, независимо от AUTHENTICATION_BACKENDS
.
Примечание
Поскольку RemoteUserBackend
наследуется от ModelBackend
, вы будете иметь все те же проверки прав доступа, которые реализованы в ModelBackend
.
Пользователям с is_active=False
не будет разрешена аутентификация. Используйте AllowAllUsersRemoteUserBackend
, если вы хотите разрешить им это.
Если ваш механизм аутентификации использует пользовательский HTTP-заголовок, а не REMOTE_USER
, вы можете подкласс RemoteUserMiddleware
и установить атрибут header
в нужный ключ request.META
. Например:
from django.contrib.auth.middleware import RemoteUserMiddleware
class CustomHeaderMiddleware(RemoteUserMiddleware):
header = 'HTTP_AUTHUSER'
Предупреждение
Будьте очень осторожны при использовании подкласса RemoteUserMiddleware
с пользовательским HTTP-заголовком. Вы должны быть уверены, что ваш внешний веб-сервер всегда устанавливает или удаляет этот заголовок на основе соответствующих проверок подлинности, никогда не позволяя конечному пользователю отправить поддельное (или «подмененное») значение заголовка. Поскольку HTTP-заголовки X-Auth-User
и X-Auth_User
(например) оба нормализуются до ключа HTTP_X_AUTH_USER
в request.META
, вы также должны убедиться, что ваш веб-сервер не допускает поддельных заголовков, использующих подчеркивание вместо тире.
Это предупреждение не относится к RemoteUserMiddleware
в его конфигурации по умолчанию с header = 'REMOTE_USER'
, поскольку ключ, не начинающийся с HTTP_
в request.META
, может быть установлен только вашим сервером WSGI, а не напрямую из заголовка HTTP запроса.
Если вам нужно больше контроля, вы можете создать свой собственный бэкенд аутентификации, который наследуется от RemoteUserBackend
и переопределить один или несколько его атрибутов и методов.
Использование REMOTE_USER
только на страницах входа в систему¶
Промежуточное ПО аутентификации RemoteUserMiddleware
предполагает, что заголовок HTTP запроса REMOTE_USER
присутствует во всех аутентифицированных запросах. Это может быть ожидаемым и практичным, когда используется Basic HTTP Auth с htpasswd
или подобные механизмы, но при использовании Negotiate (GSSAPI/Kerberos) или других ресурсоемких методов аутентификации, аутентификация на внешнем HTTP-сервере обычно устанавливается только для одного или нескольких URL входа, а после успешной аутентификации приложение должно само поддерживать аутентифицированную сессию.
PersistentRemoteUserMiddleware
обеспечивает поддержку этого варианта использования. Он будет поддерживать аутентифицированную сессию до явного выхода пользователя из системы. Этот класс можно использовать в качестве замены RemoteUserMiddleware
в документации выше.