# Django 5.2.9 ドキュメント

# `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, 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` 属性を持つユーザは認証が許可されません。許可したい場合は、`AllowAllUsersRemoteUserBackend` を使用してください。

If your authentication mechanism uses a custom HTTP header and not `REMOTE_USER`, you can subclass `RemoteUserMiddleware` and set the `header` attribute to the desired `request.META` key. For example:

`mysite/middleware.py`

     from django.contrib.auth.middleware import RemoteUserMiddleware

     class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):
         header = "HTTP_AUTHUSER"

このカスタムミドルウェアは、 `django.contrib.auth.middleware.RemoteUserMiddleware`: の代わりに `MIDDLEWARE` 設定で使用されます。

    MIDDLEWARE = [
        "...",
        "django.contrib.auth.middleware.AuthenticationMiddleware",
        "mysite.middleware.CustomHeaderRemoteUserMiddleware",
        "...",
    ]

警告

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