“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.

설정

우선, django.contrib.auth.middleware.AuthenticationMiddleware를 설정하기 전에 MIDDLEWARE에 django.contrib.auth.middleware.RemoteUserMiddleware를 추가해야 합니다.

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']에서 찾을 수 있을 것 입니다. 그리고 RemoteUserBackend를 이용하여 사용자를 증명하고 자동 로그인을 할 것입니다.

이 설정은 인증을 기본 ModelBackend로 사용하지 못하게 합니다. 그 말은 만약 REMOTE_USER 값이 설정되어 있지 않으면 Django의 관리 인터페이스를 사용한다 하더라도 사용자는 로그인할 수 없다는 것입니다. django.contrib.auth.backends.ModelBackend를 AUTHENTICATION_BACKENDS 리스트에 추가하면 REMOTE_USER가 없을 경우``ModelBackend``로 대체하여 이 문제를 해결할 수 있습니다.

contrib.admin의 뷰와 createsuperuser 관리 명령과 같은 Django의 사용자 관리는 원격 사용자와 통합할 수 없습니다. 이 인터페이스들은 AUTHENTICATION_BACKENDS와 상관없이 데이터페이스에 저장된 사용자와만 작동합니다.

참고

RemoteUserBackend는 ModelBackend를 상속하기 때문에 독자는 ModelBackend에서 구현된 권한 확인을 모두 그대로 가지고 있습니다.

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

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"

This custom middleware is then used in the MIDDLEWARE setting instead of django.contrib.auth.middleware.RemoteUserMiddleware:

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. In particular, ASGI deployments cannot be exposed directly to the internet (that is, without a reverse proxy) when using this middleware.

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 does apply by default on ASGI, because in the async path, the middleware prepends HTTP_ to the defined header name before looking it up in request.META.

만약 독자가 더 많은 제어를 필요로 할 경우, RemoteUserBackend를 상속하는 인증 백엔드를 스스로 만들어 하나 이상의 속성과 메소드를 오버라이드할 수 있습니다.

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

인증 미들웨어인 RemoteUserMiddleware는 HTTP 요청 헤더인 REMOTE_USER가 모든 인증된 요청과 함께 존재한다는 것을 가정합니다. 이것은 Basic HTTP Auth가 htpasswd 또는 기타 간단한 메커니즘들과 함께일 때 기대거나 실용적이지만, Negotiate(GSSAPI / Kerberos) 또는 기타 자원 집약적인 인증 방법과 함께 일 때는, 프런트엔드 HTTP 서버에서의 인증은 일반적으로 하나 또는 몇 개의 로그인 URL을 설정해야하고, 인증이 성공하면 응용 프로그램은 인증된 세션 자체가 유지 관리된다라는 조건이여야합니다.

PersistentRemoteUserMiddleware는 사용 사례에 대한 지원을 제공합니다. 이것은 사용자에 의하여 명시적으로 로그아웃할 때까지 인증된 세션을 유지 관리할 것 입니다. 이 클래스는 위의 문서에서 RemoteUserMiddleware 일시 대체품으로 사용되어질 수 있습니다.