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.
Web サーバーが認証を行う際には、一般に下層のアプリケーションで使用される REMOTE_USER
環境変数を設定します。Django では、request.META
属性から REMOTE_USER
が利用できます。Django は RemoteUserMiddleware
または PersistentRemoteUserMiddleware
、そして django.contrib.auth
に含まれる django.contrib.auth.backends
を使うことで REMOTE_USER
の値を利用できるように設定できます。
設定¶
最初に次のように 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
属性を持つユーザは認証が許可されません。許可したい場合は、AllowAllUsersRemoteUserBackend
を使用してください。
認証メカニズムが REMOTE_USER
以外のカスタム HTTP ヘッダを使っている場合には、以下の例のように RemoteUserMiddleware
をサブクラス化して、クラスの header
属性を適切な request.META
のキー名に設定してください:
from django.contrib.auth.middleware import RemoteUserMiddleware
class CustomHeaderMiddleware(RemoteUserMiddleware):
header = "HTTP_AUTHUSER"
警告
もし RemoteUserMiddleware
のサブクラスをカスタム HTTP ヘッダーとともに使う場合は、十分に注意してください。フロントエンドのウェブサーバは、適切な認証のチェックに基づいて、必ずヘッダーを設定または削除するようにしなければなりまません。偽の (もしくは「スプーフィングされた」) ヘッダー値を送ってくるエンドユーザーを決して許可してはいけません。たとえば、HTTP ヘッダの X-Auth-User
と X-Auth_User
は、両方とも request.META
の HTTP_X_AUTH_USER
キーに正規化されてしまうため、ウェブサーバーがダッシュの代わりにアンダースコアを使用してスプーフィングされたヘッダーを許容しないことを必ず確認しなければなりません。
この警告は、デフォルト設定の header = 'REMOTE_USER'
になっている RemoteUserMiddleware
には適用されません。なぜなら、request.META
内の HTTP_
で始まらないキーは WSGI サーバだけが設定でき、、HTTP リクエストヘッダーから直接設定されるわけではないためです。
認証メカニズムをより細かく制御したい場合は、 RemoteUserBackend
を継承する独自の認証バックエンドを作成し、属性やメソッドをいくつかオーバライドしてください。
ログインページでのみ REMOTE_USER
を使用する¶
RemoteUserMiddleware
認証ミドルウェアは、 HTTP リクエストヘッダーの REMOTE_USER
が認証されたリクエストに存在していることを想定しています。これは、htpasswd
や同様のメカニズムを備えた Basic 認証であれば妥当で実用的かもしれませんが、Negotiate (GSSAPI/Kerberos) や他のリソース中心的な認証メソッドでは、フロントエンド HTTP サーバ内の認証は、通常、1つまたは少数のログイン URL しか設置せず、認証の成功後にもアプリケーションが認証されたセッション自体を維持することが想定されています。
PersistentRemoteUserMiddleware
は、このようなユースケースへのサポートを提供します。このミドルウェアは、ユーザーが明示的にログアウトするまで、認証されたセッションを維持しようとします。このクラスは、上述のドキュメント内の RemoteUserMiddleware
とドロップインで交換できます。