Аутентификация с использованием 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_CLASSES после django.contrib.auth.middleware.AuthenticationMiddleware:

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

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