# Django 5.0.9.dev20240806133106 ドキュメント

# `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` の設定にかかわらず、データベース中のユーザだけを管理します。

注釈

`RemoteUserBackend` を `ModelBackend` から継承した後も、`ModelBackend` によってチェックが行われ、すべてのパーミッションが維持されます。

`is_active=False` 属性を持つユーザは認証が許可されません。許可したい場合は、`AllowAllUsersRemoteUserBackend` を使用してください。

認証メカニズムが `REMOTE_USER` 以外のカスタム HTTP ヘッダを使っている場合には、以下の例のように `RemoteUserMiddleware` をサブクラス化して、クラスの `header` 属性を適切な `request.META` のキー名に設定してください:

    from django.contrib.auth.middleware import RemoteUserMiddleware

    class CustomHeaderMiddleware(RemoteUserMiddleware):
        header = "HTTP_AUTHUSER"

警告

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