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 設定の 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 の設定にかかわらず、データベース中のユーザだけを管理します。
注釈
Since the RemoteUserBackend inherits from ModelBackend, you will
still have all of the same permissions checking that is implemented in
ModelBackend.
Users with is_active=False won’t be allowed to
authenticate. Use
AllowAllUsersRemoteUserBackend if
you want to allow them to.
In older versions, inactive users weren’t rejected as described above.
認証メカニズムが 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.
