• 3.1
  • 3.2
  • 5.0
  • Версия документации: 6.1

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

This document describes how to make use of external authentication sources (where the web server sets the REMOTE_USER environment variable) in your Django applications. This type of authentication solution is typically seen on intranet sites, with single sign-on solutions such as IIS and Integrated Windows Authentication or Apache and mod_authnz_ldap, CAS, WebAuth, mod_auth_sspi, etc.

When the web server takes care of authentication it typically sets the REMOTE_USER environment variable for use in the underlying application. In Django, REMOTE_USER is made available in the request.META attribute. Django can be configured to make use of the REMOTE_USER value using the RemoteUserMiddleware or PersistentRemoteUserMiddleware, and RemoteUserBackend classes found in 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, если хотите позволить им авторизоваться.

If your authentication mechanism uses a custom HTTP header and not REMOTE_USER, you can subclass RemoteUserMiddleware and set the header attribute to the desired request.META key. For example:

mysite/middleware.py
 from django.contrib.auth.middleware import RemoteUserMiddleware


 class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):
     header = "HTTP_AUTHUSER"

Эта кастомная middleware будет использоваться в списке MIDDLEWARE вместо django.contrib.auth.middleware.RemoteUserMiddleware:

MIDDLEWARE = [
    "...",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "mysite.middleware.CustomHeaderRemoteUserMiddleware",
    "...",
]

Предупреждение

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

This warning doesn’t apply to RemoteUserMiddleware in its default configuration with header = 'REMOTE_USER', since a key that doesn’t start with HTTP_ in request.META can only be set by your WSGI or ASGI server, not directly from an HTTP request header.

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

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

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

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

Back to Top