Аутентификация при помощи REMOTE_USER

Документ описывает использование внешних источников аутентификации (когда на веб-сервере установлена переменная REMOTE_USER) в приложениях Django. Этот тип аутентификации является типичным для интранет-сайтов, использующих такие решения как IIS и Integrated Windows Authentication или Apache и mod_authnz_ldap, CAS, Cosign, WebAuth, mod_auth_sspi.

Для обеспечения наибольшей безопасности Web-сервер устанавливает переменную окружения 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 заголовка. Вы должны быть уверенны, что внешний(front-end) веб-сервер всегда устанавливает или удаляет этот заголовок при проверке авторизации, не позволяя пользователю явно передать неверное или поддельное значение. Т.к. HTTP заголовки X-Auth-User и X-Auth_User (например) приводятся к HTTP_X_AUTH_USER в request.META, веб сервер также должен предотвращать подделку этих заголовков, путем использования подчеркивания вместо дефиса.

Это замечание не относится к параметрам по умолчанию для RemoteUserMiddleware``(``header = 'REMOTE_USER'), т.к. ключ без HTTP_ в request.META может быть установлен только WSGI сервером, а не HTTP заголовком запроса.

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

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

Аутентификационный модуль RemoteUserMiddleware предполагает, что HTTP заголовок REMOTE_USER присутствует во всех аутентификационных запросах. Это удобно при использовании Basic HTTP Auth с помощью htpasswd или подобных механизмов, но для Negotiate (GSSAPI/Kerberos) или при использовании других сложных механизмов аутентификации, аутентификация на «front-end» HTTP сервере обычно устанавливается для одного или нескольких URL-ов страниц входа, и после успешной авторизации предполагается, что приложения будет самостоятельно работать с сессией.

PersistentRemoteUserMiddleware предоставляет такую возможность. Сессия пользователя поддерживается, пока пользователь явно не выполнит выход. Этот класс может использоваться вместо RemoteUserMiddleware.