Авторизация с использованием REMOTE_USER

В этом документе описано, как использовать внешние источники авторизации (где веб-сервер устанавливает переменную среды REMOTE_USER ) в ваших приложениях Django. Этот тип решения для авторизации обычно используется на внутрисетевых сайтах с решениями единого входа, такими как IIS и Integrated Windows Authentication или 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 Basic с htpasswd или других простых механизмов, но при использовании аутентификации Negotiate (GSSAPI/Kerberos) или других ресурсоёмких методов авторизации аутентификация на веб-сервере переднего плана обычно настраивается только для одной или нескольких страниц входа, а после успешной авторизации приложение должно само поддерживать аутентифицированную сессию.

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