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'

警告

Be very careful if using a RemoteUserMiddleware subclass with a custom HTTP header. You must be sure that your front-end web server always sets or strips that header based on the appropriate authentication checks, never permitting an end-user to submit a fake (or "spoofed") header value. Since the HTTP headers X-Auth-User and X-Auth_User (for example) both normalize to the HTTP_X_AUTH_USER key in request.META, you must also check that your web server doesn't allow a spoofed header using underscores in place of dashes.

This warning doesn't apply to RemoteUserMiddleware in its default configuration with header = 'REMOTE_USER', since a key that doesn't start with HTTP_ in request.META can only be set by your WSGI server, not directly from an HTTP request header.

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

Using REMOTE_USER on login pages only

The RemoteUserMiddleware authentication middleware assumes that the HTTP request header REMOTE_USER is present with all authenticated requests. That might be expected and practical when Basic HTTP Auth with htpasswd or other simple mechanisms are used, but with Negotiate (GSSAPI/Kerberos) or other resource intensive authentication methods, the authentication in the front-end HTTP server is usually only set up for one or a few login URLs, and after successful authentication, the application is supposed to maintain the authenticated session itself.

PersistentRemoteUserMiddleware provides support for this use case. It will maintain the authenticated session until explicit logout by the user. The class can be used as a drop-in replacement of RemoteUserMiddleware in the documentation above.