Авторизация с использованием 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) или другими ресурсоёмкими методами аутентификации, аутентификация на front-end HTTP-сервере обычно настраивается только для одной или нескольких страниц входа, а после успешной аутентификации приложение должно самостоятельно поддерживать аутентифицированную сессию.

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