REMOTE_USER を使用した認証

このドキュメントでは、Django アプリケーション内での外部の認証ソースの使用方法について説明します。たとえば、Web サーバが REMOTE_USER を設定するような場合です。このような認証方法は、単一認証 (single sign-on) システムを利用するイントラネットサイトの多くで典型的に見られるものです。単一認証システムの例としては、'IIS と統合 Windows 認証の組み合わせや、Apache と mod_authnz_ldap, CAS, Cosign, WebAuth, mod_auth_sspi などの組み合わせがあります。

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 設定の ModelBackendRemoteUserBackend に変更します:

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

この設定を行うと RemoteUserMiddlewarerequest.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-UserX-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 の当座の代替として使うことができる。