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 とドロップインで交換できます。

Back to Top