How to authenticate 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.

設定

最初に次のように MIDDLEWARE 設定に django.contrib.auth.middleware.RemoteUserMiddleware を加える必要があります。これは django.contrib.auth.middleware.AuthenticationMiddleware の 後に 追加してください:

MIDDLEWARE = [
    '...',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.auth.middleware.RemoteUserMiddleware',
    '...',
]

続いて、AUTHENTICATION_BACKENDS 設定の ModelBackend を RemoteUserBackend に変更します:

AUTHENTICATION_BACKENDS = [
    'django.contrib.auth.backends.RemoteUserBackend',
]

この設定を行うと RemoteUserMiddleware は request.META['REMOTE_USER'] 内の username を検索し、 RemoteUserBackend を使用したユーザーの認証と自動ログインを行います。

この特定の設定は、デフォルトの ModelBackend による認証を無効にすることに注意してください。つまり、 REMOTE_USER の値が設定されていなければ、Django の admin interface を使ったとしても、ユーザーはログインすることができないということです。 REMOTE_USER が存在しない場合のフォールバックとして AUTHENTICATION_BACKENDS のリストに 'django.contrib.auth.backends.ModelBackend' を追加しておけば、この問題は解決できます。

contrib.admin 画面や createsuperuser 管理コマンドなどの、Django のユーザ管理機能はリモートユーザを統合管理しません。これらのインタフェースは AUTHENTICATION_BACKENDS の設定にかかわらず、データベース中のユーザだけを管理します。

注釈

``RemoteUserBackend``を``ModelBackend``から継承した後も、``ModelBackend``によってチェックが行われ、すべてのパーミッションが維持されます。

is_active=False 属性を持つユーザは認証が許可されません。許可したい場合は、:class:`~django.contrib.auth.backends.AllowAllUsersRemoteUserBackend`を使用してください。

認証メカニズムが REMOTE_USER 以外のカスタム HTTP ヘッダを使っている場合には、以下の例のように RemoteUserMiddleware をサブクラス化して、クラスの header 属性を適切な request.META のキー名に設定してください:

from django.contrib.auth.middleware import RemoteUserMiddleware

class CustomHeaderMiddleware(RemoteUserMiddleware):
    header = 'HTTP_AUTHUSER'

警告

もし RemoteUserMiddleware のサブクラスをカスタム HTTP ヘッダーとともに使う場合は、慎重になってください. フロントエンドの Web サーバは、必ず、いつもでも適切な認証のチェックに基づいたヘッダーを設置または削除してください。決して偽の（もしくは『スプーフィングされた』）ヘッダー値を送ってくるエンドユーザーを許可してはいけません。例えば、 HTTP ヘッダの X-Auth-User と X-Auth_User は両方とも request.META のキー HTTP_X_AUTH_USER に正規化されてしまうので、 ダッシュの代わりにアンダースコアを使ったスプーフィングされたヘッダーを許容していないかもまた必ずチェックしてください。

この警告は、header = 'REMOTE_USER' になっているデフォルト設定の RemoteUserMiddleware には適用されません。それは、 request.META 内の HTTP_ で始まらないキーは、HTTP リクエストヘッダーに直接設置されるのではなく、 WSGI サーバによって設置されるからです。

認証メカニズムをより細かく制御したければ、 RemoteUserBackend を継承する独自の認証バックエンドを作成し、属性やメソッドをいくつかオーバライドしてください。

ログインページでのみ REMOTE_USER を使用する

RemoteUserMiddleware 認証ミドルウェアは、 HTTP リクエストヘッダーの REMOTE_USER が認証されたリクエストに存在していることを仮定しています。これが htpasswd、または同様のメカニズムを備えた Basic 認証なら、妥当で実用的かもしれませんが、ネゴシエート(GSSAPI/ケルベロス)や他の資源を利用した認証メソッドでは、フロントエンド HTTP サーバの認証では、通常、ひとつもしくはいくつかのログイン URL のみ設置します。そして、認証が成功した後、アプリケーションは認証されたセッションそれ自体を維持しようとします。

PersistentRemoteUserMiddleware は、この使用事例の補助を提供する。これは、はっきりとユーザーにログアウトされるまで、認証されたセッションを維持しようとする。このクラスは、このドキュメントの上にある RemoteUserMiddleware の当座の代替として使うことができる。

« previous | up | next »