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

Authentication using 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, Cosign, 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:

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.

Back to Top