# Django 4.1.8.dev20230308103347 ドキュメント

# How to authenticate using `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, Cosign, 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` 属性を持つユーザは認証が許可されません。許可したい場合は、: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-User` と `X-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` の当座の代替として使うことができる。