``REMOTE_USER``를 사용하여 인증

이 문서는 Django applications에서 외부 인증 소스(REMOTE_USER 환경변수를 설정한 웹서버)를 사용하는 방법에 대해 적혀 있습니다. 이러한 인증 방법은 대게 인트라넷, IIS와 통합된 윈도우즈 인증 또는 Apahe 의 mod_authnz_ldap, CAS, WebAuth, mod_auth_sspi 등과 같은 single sign-on 솔루션 에서 볼 수 있습니다.

웹 서버에서 인증을 관리할때 대게 내부 어플리케이션을 사용하기 위해 REMOTE_USER 환경 변수를 설정합니다. REMOTE_USER 값은 RemoteUserMiddleware 혹은 PersistentRemoteUserMiddleware 에서 사용됩니다. django.contrib.auth`에서 :class:`~django.contrib.auth.backends.RemoteUserBackend 클래스를 찾을 수 있습니다.


처음으로, django.contrib.auth.middleware.AuthenticationMiddleware::를 설정하기 전에 MIDDLEWAREdjango.contrib.auth.middleware.RemoteUserMiddleware 를 추가해야 합니다.


그 다음 , AUTHENTICATION_BACKENDS 세팅에 있는 ModelBackendRemoteUserBackend 로 바꾸어 주어야 합니다.


설정을 마치고 난 후, ``RemoteUserMiddleware``는 유저네임을 ``request.META[‘REMOTE_USER’]``에서 찾을 수 있을 것 입니다. 그리고 :class:`~django.contrib.auth.backends.RemoteUserBackend`를 이용하여 사용자를 증명하고 자동 로그인을 할 것 입니다.

Be aware that this particular setup disables authentication with the default ModelBackend. This means that if the REMOTE_USER value is not set then the user is unable to log in, even using Django’s admin interface. Adding 'django.contrib.auth.backends.ModelBackend' to the AUTHENTICATION_BACKENDS list will use ModelBackend as a fallback if REMOTE_USER is absent, which will solve these issues.

Django’s user management, such as the views in contrib.admin and the createsuperuser management command, doesn’t integrate with remote users. These interfaces work with users stored in the database regardless of AUTHENTICATION_BACKENDS.


Since the RemoteUserBackend inherits from ModelBackend, you will still have all of the same permissions checking that is implemented in ModelBackend.

Users with is_active=False won’t be allowed to authenticate. Use AllowAllUsersRemoteUserBackend if you want to allow them to.

Changed in Django 1.10:

과거 버전들에서는, 비활성화된 사용자의 경우에도 위에 묘사된 대로 거부되지 않습니다.

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:

from django.contrib.auth.middleware import RemoteUserMiddleware

class CustomHeaderMiddleware(RemoteUserMiddleware):
    header = 'HTTP_AUTHUSER'


Be very careful if using a RemoteUserMiddleware subclass with a custom HTTP header. You must be sure that your front-end web server 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.

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.

If you need more control, you can create your own authentication backend that inherits from RemoteUserBackend and override one or more of its attributes and methods.

``REMOTE_USER`는 로그인 페이지에서만 사용할 수 있습니다.

New in Django 1.9.

The RemoteUserMiddleware authentication middleware assumes that the HTTP request header REMOTE_USER is present with all authenticated requests. That might be expected and practical when Basic HTTP Auth with htpasswd or other simple mechanisms are used, but with Negotiate (GSSAPI/Kerberos) or other resource intensive authentication methods, the authentication in the front-end HTTP server is usually only set up for one or a few login URLs, and after successful authentication, the application is supposed to maintain the authenticated session itself.

PersistentRemoteUserMiddleware provides support for this use case. It will maintain the authenticated session until explicit logout by the user. The class can be used as a drop-in replacement of RemoteUserMiddleware in the documentation above.