---
title: "How to authenticate using REMOTE_USER"
version: 4.1
locale: ja
source: https://docs.djangoproject.com/ja/4.1/howto/auth-remote-user/
canonical: https://djangodocs.dev/ja/4.1/howto/auth-remote-user/
---
# 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](https://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html), [CAS](https://www.apereo.org/projects/cas), [Cosign](http://weblogin.org),
[WebAuth](https://uit.stanford.edu/service/authentication), [mod\_auth\_sspi](https://sourceforge.net/projects/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`](/ja/4.1/ref/request-response/#django.http.HttpRequest.META) attribute.  Django can be configured to make
use of the `REMOTE_USER` value using the `RemoteUserMiddleware`
or `PersistentRemoteUserMiddleware`, and
[`RemoteUserBackend`](/ja/4.1/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) classes found in
[`django.contrib.auth`](/ja/4.1/topics/auth/#module-django.contrib.auth).

## 設定

最初に次のように [`MIDDLEWARE`](/ja/4.1/ref/settings/#std-setting-MIDDLEWARE) 設定に [`django.contrib.auth.middleware.RemoteUserMiddleware`](/ja/4.1/ref/middleware/#django.contrib.auth.middleware.RemoteUserMiddleware) を加える必要があります。これは [`django.contrib.auth.middleware.AuthenticationMiddleware`](/ja/4.1/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware) の **後に** 追加してください:

```
MIDDLEWARE = [
    '...',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.auth.middleware.RemoteUserMiddleware',
    '...',
]
```

続いて、[`AUTHENTICATION_BACKENDS`](/ja/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) 設定の [`ModelBackend`](/ja/4.1/ref/contrib/auth/#django.contrib.auth.backends.ModelBackend) を [`RemoteUserBackend`](/ja/4.1/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) に変更します:

```
AUTHENTICATION_BACKENDS = [
    'django.contrib.auth.backends.RemoteUserBackend',
]
```

この設定を行うと `RemoteUserMiddleware` は `request.META['REMOTE_USER']` 内の username を検索し、 [`RemoteUserBackend`](/ja/4.1/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) を使用したユーザーの認証と自動ログインを行います。

この特定の設定は、デフォルトの `ModelBackend` による認証を無効にすることに注意してください。つまり、 `REMOTE_USER` の値が設定されていなければ、Django の admin interface を使ったとしても、ユーザーはログインすることができないということです。 `REMOTE_USER` が存在しない場合のフォールバックとして `AUTHENTICATION_BACKENDS` のリストに `'django.contrib.auth.backends.ModelBackend'`  を追加しておけば、この問題は解決できます。

`contrib.admin` 画面や [`createsuperuser`](/ja/4.1/ref/django-admin/#django-admin-createsuperuser) 管理コマンドなどの、Django のユーザ管理機能はリモートユーザを統合管理しません。これらのインタフェースは `AUTHENTICATION_BACKENDS` の設定にかかわらず、データベース中のユーザだけを管理します。

> **Note**
>
> RemoteUserBackend\`\`を\`\`ModelBackend\`\`から継承した後も、ModelBackend\`\`によってチェックが行われ、すべてのパーミッションが維持されます。
>
> [`is_active=False`](/ja/4.1/ref/contrib/auth/#django.contrib.auth.models.User.is_active) 属性を持つユーザは認証が許可されません。許可したい場合は、: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'
```

> **Warning**
>
> もし `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`](/ja/4.1/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) を継承する独自の認証バックエンドを作成し、属性やメソッドをいくつかオーバライドしてください。

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

`RemoteUserMiddleware` 認証ミドルウェアは、 HTTP リクエストヘッダーの `REMOTE_USER` が認証されたリクエストに存在していることを仮定しています。これが `htpasswd`、または同様のメカニズムを備えた Basic 認証なら、妥当で実用的かもしれませんが、ネゴシエート(GSSAPI/ケルベロス)や他の資源を利用した認証メソッドでは、フロントエンド HTTP サーバの認証では、通常、ひとつもしくはいくつかのログイン URL のみ設置します。そして、認証が成功した後、アプリケーションは認証されたセッションそれ自体を維持しようとします。

[`PersistentRemoteUserMiddleware`](/ja/4.1/ref/middleware/#django.contrib.auth.middleware.PersistentRemoteUserMiddleware) は、この使用事例の補助を提供する。これは、はっきりとユーザーにログアウトされるまで、認証されたセッションを維持しようとする。このクラスは、このドキュメントの上にある [`RemoteUserMiddleware`](/ja/4.1/ref/middleware/#django.contrib.auth.middleware.RemoteUserMiddleware) の当座の代替として使うことができる。