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.

設定

最初に次のように 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 を使用してください。

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"

このカスタムミドルウェアは、 django.contrib.auth.middleware.RemoteUserMiddleware: の代わりに MIDDLEWARE 設定で使用されます。

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

警告

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