Аутентификация с использованием REMOTE_USER
¶
Этот документ описывает, как использовать внешние источники аутентификации (где веб-сервер устанавливает REMOTE_USER
переменную среды) в ваших приложениях Django. Этот тип решения аутентификации обычно рассматривается на сайтах интрасети, с единого входа решений , таких как IIS и встроенная проверка подлинности Windows или Apache и mod_authnz_ldap , CAS , CoSign ,
WebAuth , mod_auth_sspi и т.д.
Когда веб-сервер заботится об аутентификации, он обычно устанавливает
REMOTE_USER
переменную среды для использования в базовом приложении. В Django REMOTE_USER
это доступно в request.META
атрибуте. Django можно настроить для использования REMOTE_USER
значения с помощью классов RemoteUserMiddleware
или PersistentRemoteUserMiddleware
и,
RemoteUserBackend
найденных в
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
конфигурации по умолчанию с , поскольку ключ, который не начинается с in, может быть установлен только вашим сервером WSGI, а не непосредственно из заголовка HTTP-запроса.header = 'REMOTE_USER'
HTTP_
request.META
Если вам нужен больший контроль, вы можете создать свой собственный сервер аутентификации, который наследует RemoteUserBackend
и переопределяет один или несколько его атрибутов и методов.
Использование только REMOTE_USER
на страницах входа ¶
По RemoteUserMiddleware
промежуточного слоя аутентификации предполагается, что заголовок HTTP-запроса REMOTE_USER
присутствует во всех аутентифицированных запросах. Этого можно ожидать и практично, когда используется базовая HTTP-аутентификация с htpasswd
или аналогичными механизмами, но с использованием согласования (GSSAPI / Kerberos) или других ресурсоемких методов аутентификации аутентификация на внешнем HTTP-сервере обычно настраивается только для одного или несколько URL-адресов для входа, и после успешной аутентификации приложение должно поддерживать аутентифицированный сеанс.
PersistentRemoteUserMiddleware
обеспечивает поддержку для этого варианта использования. Он будет поддерживать сеанс с аутентификацией до явного выхода пользователя из системы. Класс можно использовать как замену RemoteUserMiddleware
в документации выше.