# documentación de Django - 6.0.7

# Cómo autenticarse usando `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`.

## Configuración

Primero debe agregar la clase `django.contrib.auth.middleware.RemoteUserMiddleware` a la configuración de `MIDDLEWARE` después de `django.contrib.auth.middleware.AuthenticationMiddleware`:

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

Luego, debe remplazar la clase `ModelBackend` por `RemoteUserBackend` en la configuración `AUTHENTICATION_BACKENDS`:

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

Sea conciente de que esta configuración particular deshabilita la autenticación por defecto con el `ModelBackend`. Esto significa que si el valor del `REMOTE_USER` no está definido, entonces el usuario no será capaz de ingresar, incluso usando la interfaz de administración de Django. Agregando `'django.contrib.auth.backends.ModelBackend'` a la lista de `AUTHENTICATION_BACKENDS`, servirá como respaldo si `REMOTE_USER` no está definido, lo que resolverá estas problemáticas.

El sistema de usuarios de Django, como las vistas en `contrib.admin` y el comando de manejo `createsuperuser`, no se integran con usuarios remotos. Estas interfaces trabajan con usuarios almacenados en la base de datos independientemente de `AUTHENTICATION_BACKENDS`.

Nota

Como `RemoteUserBackend` hereda de `ModelBackend`, todavía tendrá la misma comprobación de permisos implementada en `ModelBackend`.

Usuarios con `is_active=False` no serán capaces de autenticarse. Use `AllowAllUsersRemoteUserBackend` si quiere permitirles hacerlo.

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"

Este middleware personalizado luego se usa en el parámetro `MIDDLEWARE` de la configuración en vez de `django.contrib.auth.middleware.RemoteUserMiddleware`:

    MIDDLEWARE = [
        "...",
        "django.contrib.auth.middleware.AuthenticationMiddleware",
        "mysite.middleware.CustomHeaderRemoteUserMiddleware",
        "...",
    ]

Advertencia

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

Si necesita más control, puedes crear su propio backend de autenticación que herede de `RemoteUserBackend` y redefinir uno o más de sus atributos y métodos.

## Usando `REMOTE_USER` en paginas de ingreso solamente

El middleware de autenticación `RemoteUserMiddleware` asume que el encabezado de solicitud HTTP `REMOTE_USER` está presente con todas las solicitudes autenticadas. Eso podría ser esperado y práctico cuando se utiliza autenticación HTTP básica con `htpasswd` o mecanismos similares, pero con Negotiate (GSSAPI/Kerberos) u otros métodos de autenticación intensivos en recursos, la autenticación en el servidor HTTP front-end normalmente solo se configura para una o varias direcciones URL de inicio de sesión, y después de una autenticación correcta, se supone que la aplicación debe mantener la sesión autenticada.

`PersistentRemoteUserMiddleware` proporciona soporte para este caso de uso. Mantendrá la sesión autenticada hasta que el usuario cierre la sesión explícitamente. La clase se puede utilizar como un reemplazo directo de `RemoteUserMiddleware` en la documentación anterior.