REMOTE_USERを使用した認証
このドキュメントでは、Djangoアプリケーションで外部認証ソース（WebサーバーがREMOTE_USER環境変数を設定する場所）を利用する方法について説明します。 このタイプの認証ソリューションは通常、IISや統合Windows認証またはApacheや mod_authnz_ldap 、 CAS 、 Cosign などのシングルサインオンソリューションを備えたイントラネットサイトで見られます。 ]、 WebAuth 、 mod_auth_sspi など。
Webサーバーが認証を処理する場合、通常、基盤となるアプリケーションで使用するためにREMOTE_USER環境変数を設定します。 Djangoでは、REMOTE_USERは request.META 属性で使用可能になります。 Djangoは、RemoteUserMiddlewareまたはPersistentRemoteUserMiddleware、および django.contribにある RemoteUserBackend クラスを使用して、REMOTE_USER値を利用するように構成できます。 auth 。
構成
まず、 django.contrib.auth.middleware.RemoteUserMiddleware を：setting： `MIDDLEWARE` 設定 after django.contribに追加する必要があります.auth.middleware.AuthenticationMiddleware ：
MIDDLEWARE = [
'...',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.RemoteUserMiddleware',
'...',
]次に、：setting： `AUTHENTICATION_BACKENDS` 設定で、 ModelBackend を RemoteUserBackend に置き換える必要があります。
AUTHENTICATION_BACKENDS = [
'django.contrib.auth.backends.RemoteUserBackend',
]この設定では、RemoteUserMiddlewareはrequest.META['REMOTE_USER']のユーザー名を検出し、 RemoteUserBackend を使用してそのユーザーを認証および自動ログインします。
この特定の設定では、デフォルトのModelBackendで認証が無効になることに注意してください。 これは、REMOTE_USERの値が設定されていない場合、ユーザーはDjangoの管理インターフェースを使用してもログインできないことを意味します。 'django.contrib.auth.backends.ModelBackend'をAUTHENTICATION_BACKENDSリストに追加すると、REMOTE_USERがない場合のフォールバックとして、ModelBackendが使用され、これらの問題が解決されます。
contrib.adminのビューや：djadmin： `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'警告
カスタムHTTPヘッダーでRemoteUserMiddlewareサブクラスを使用する場合は、十分に注意してください。 フロントエンドWebサーバーが常に適切な認証チェックに基づいてそのヘッダーを設定または削除し、エンドユーザーが偽の（または「なりすまし」）ヘッダー値を送信することを許可しないようにする必要があります。 HTTPヘッダーX-Auth-UserとX-Auth_User（たとえば）はどちらもrequest.METAのHTTP_X_AUTH_USERキーに正規化されるため、Webサーバーがtダッシュの代わりにアンダースコアを使用してスプーフィングされたヘッダーを許可します。
request.METAのHTTP_で始まらないキーはHTTPリクエストヘッダーから直接ではなく、WSGIサーバーによって設定されます。
さらに制御が必要な場合は、 RemoteUserBackend から継承する独自の認証バックエンドを作成し、その属性とメソッドの1つ以上をオーバーライドできます。
ログインページでのみREMOTE_USERを使用する
RemoteUserMiddleware認証ミドルウェアは、HTTPリクエストヘッダーREMOTE_USERがすべての認証済みリクエストに存在することを前提としています。 これは、htpasswdまたは同様のメカニズムを使用した基本HTTP認証が使用されている場合に予想され実用的ですが、ネゴシエート（GSSAPI / Kerberos）またはその他のリソースを大量に消費する認証方法では、フロントエンドHTTPサーバーでの認証は通常のみです。 1つまたはいくつかのログインURLを設定し、認証が成功した後、アプリケーションは認証されたセッション自体を維持することになっています。
PersistentRemoteUserMiddleware は、このユースケースのサポートを提供します。 ユーザーが明示的にログアウトするまで、認証されたセッションを維持します。 このクラスは、上記のドキュメントの RemoteUserMiddleware のドロップイン置換として使用できます。
