Как выполнить аутентификацию с помощью 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.

Если ваш механизм аутентификации использует настраиваемый HTTP-заголовок, а не REMOTE_USER, вы можете создать подкласс RemoteUserMiddleware и установить атрибут header на желаемый ключ request.META. Например:

from django.contrib.auth.middleware import RemoteUserMiddleware


class CustomHeaderMiddleware(RemoteUserMiddleware):
    header = "HTTP_AUTHUSER"

Если вам нужен больший контроль, вы можете создать собственный модуль аутентификации, унаследованный от RemoteUserBackend и переопределить один или несколько его атрибутов и методов.

Использование REMOTE_USER только на страницах входа

Модуль аутентификации RemoteUserMiddleware предполагает, что HTTP-заголовок запроса REMOTE_USER присутствует во всех аутентифицированных запросах. Это может быть ожидаемо и практично при использовании базовой HTTP-аутентификации с htpasswd или аналогичными механизмами, но с механизмами аутентификации, такими как Negotiate (GSSAPI/Kerberos) или другими ресурсоёмкими методами, аутентификация на фронтенд-веб-сервере обычно устанавливается только для одной или нескольких страниц входа, а после успешной аутентификации приложение должно поддерживать аутентифицированную сессию самостоятельно.

PersistentRemoteUserMiddleware поддерживает этот случай использования. Он будет сохранять аутентифицированную сессию до явного выхода пользователя. Класс может быть использован как замена RemoteUserMiddleware в приведенном выше документе.