# Django 6.0.7 ドキュメント

# `REMOTE_USER` で認証する

This document describes how to make use of external authentication sources 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 provides the authenticated user as `REMOTE_USER`. In Django, this value is made available in `request.META` (as `REMOTE_USER` when supplied as an environment variable, as in WSGI, or `HTTP_REMOTE_USER` when supplied via an HTTP header, as in ASGI). 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",
    ]

With this setup, `RemoteUserMiddleware` will detect the username in `request.META['REMOTE_USER']` (or `request.META['HTTP_REMOTE_USER']` under ASGI) and will authenticate and auto-login that user using the `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` must not be deployed in configurations where a client can supply the header. You must be sure that your web server or reverse proxy 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.

Under WSGI, 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.

This warning applies under ASGI in all configurations, because there is no equivalent for a WSGI server's ability to place a trusted value in the environ. ASGI deployments must use a reverse proxy as described above when using this middleware.

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

## ログインページでのみ `REMOTE_USER` を使用する

`RemoteUserMiddleware` 認証ミドルウェアは、 HTTP リクエストヘッダーの `REMOTE_USER` が認証されたリクエストに存在していることを想定しています。これは、`htpasswd` や同様のメカニズムを備えた Basic 認証であれば妥当で実用的かもしれませんが、Negotiate (GSSAPI/Kerberos) や他のリソース中心的な認証メソッドでは、フロントエンド HTTP サーバ内の認証は、通常、1つまたは少数のログイン URL しか設置せず、認証の成功後にもアプリケーションが認証されたセッション自体を維持することが想定されています。

`PersistentRemoteUserMiddleware` は、このようなユースケースへのサポートを提供します。このミドルウェアは、ユーザーが明示的にログアウトするまで、認証されたセッションを維持しようとします。このクラスは、上述のドキュメント内の `RemoteUserMiddleware` とドロップインで交換できます。