Uso de NGINX Plus y NGINX para autenticar usuarios de aplicação con LDAP

Los clientes nos preguntan con frecuencia cómo pueden utilizar NGINX Plus y NGINX para proteger recursos o aplicações mediante la autenticación de los usuarios que los solicitan. Hoy anunciamos una implementación de referencia de dicho sistema de autenticación y la ponemos a disposición en el repositorio de NGINX, Inc. en GitHub . En esta publicación describimos cómo funciona la implementación, cómo instalarla y cómo usarla como modelo para su propio sistema de autenticación.

La solución aprovecha el módulo ngx_http_auth_request_module en NGINX Plus y NGINX, que reenvía solicitudes de autenticación a un servicio externo. En la implementación de referencia, ese servicio es un demonio que llamamos ldap‑auth . Está escrito en Python y se comunica con un servidor de autenticación de Protocolo ligero de acceso a directorios (LDAP), OpenLDAP de manera predeterminada, pero también hemos probado el demonio ldap‑auth con configuraciones predeterminadas de Microsoft® Windows® Server Active Directory (tanto la versión 2003 como la 2012).

El demonio ldap-auth sirve como modelo para su propia aplicación “conectora”, que puede escribir en otros lenguajes, implementar con diferentes sistemas de autenticación o ambas cosas. El equipo de Servicios Profesionales de NGINX está disponible para ayudar con dichas adaptaciones.

Notas:

• La implementación de referencia no está destinada para uso en producción, sino únicamente como modelo para sus propias implementaciones.
• Para facilitar la lectura, el resto de este artículo se refiere a NGINX Plus, pero la implementación de referencia también funciona con NGINX Open Source. El módulo http_auth_request, requisito previo, está incluido tanto en los paquetes NGINX Plus como en los binarios NGINX prediseñados .

Cómo funciona la autenticación en la implementación de referencia

Para realizar la autenticación, el módulo http_auth_request realiza una subsolicitud HTTP al demonio ldap‑auth, que actúa como intermediario e interpreta la subsolicitud para el servidor LDAP: utiliza HTTP para la comunicación con NGINX Plus y la API adecuada para la comunicación con el servidor LDAP.

Suponemos que si está interesado en la implementación de referencia, ya tiene una aplicação u otros recursos que desea proteger requiriendo autenticación. Sin embargo, para facilitar la prueba de la implementación de referencia, proporcionamos un demonio de backend de muestra, también escrito en Python, que escucha en el puerto 9000. Puede reemplazar una aplicação HTTP real durante las pruebas, solicitando credenciales de usuario y creando una cookie basada en ellas.

A continuación se muestra una descripción paso a paso del proceso de autenticación en la implementación de referencia. Los detalles están determinados por las configuraciones en el archivo de configuración nginx-ldap-auth.conf ; consulte Configurar la implementación de referencia a continuación. El diagrama de flujo debajo de los pasos resume el proceso.

1. Un cliente envía una solicitud HTTP para un recurso protegido alojado en un servidor para el cual NGINX Plus actúa como proxy inverso.

2. NGINX Plus (específicamente, el módulo http_auth_request) reenvía la solicitud al demonio ldap‑auth, que responde con el código HTTP401 porque no se proporcionaron credenciales.

3. NGINX Plus reenvía la solicitud a http://backend/login , que corresponde al demonio backend. Escribe la URI de solicitud original en el encabezado X-Target de la solicitud reenviada.

4. El demonio backend envía al cliente un formulario de inicio de sesión (el formulario está definido en el código Python para el demonio). Según lo configurado por la directiva error_page , NGINX establece el código HTTP en el formulario de inicio de sesión en200 .

5. El usuario completa los campos Nombre de usuario y Contraseña en el formulario y hace clic en el botón Iniciar sesión. Según el código del formulario, el cliente genera una solicitud HTTP POST dirigida a /login , que NGINX Plus reenvía al demonio backend.

6. El demonio de backend construye una cadena con el formato nombre de usuario : contraseña , aplica codificación Base64, genera una cookie llamada nginxauth con su valor establecido en la cadena codificada y envía la cookie al cliente. Establece el indicador httponly para evitar el uso de JavaScript para leer o manipular la cookie (protegiendo contra la vulnerabilidad de scripts entre sitios [XSS] ).

7. El cliente retransmite su solicitud original (del Paso 1), esta vez incluyendo la cookie en el campo Cookie del encabezado HTTP. NGINX Plus reenvía la solicitud al demonio ldap-auth (como en el paso 2).

8. El demonio ldap‑auth decodifica la cookie y envía el nombre de usuario y la contraseña al servidor LDAP en una solicitud de autenticación.

9. La siguiente acción depende de si el servidor LDAP autentica correctamente al usuario:

   • Si la autenticación es exitosa, el demonio ldap‑auth envía el código HTTP200 a NGINX Plus. NGINX Plus solicita el recurso al demonio backend. En la implementación de referencia, el demonio backend devuelve el siguiente texto:

        ¡Hola Mundo! URL solicitada: URL
     

     El archivo nginx-ldap-auth.conf incluye directivas para almacenar en caché los resultados del intento de autenticación; para deshabilitar el almacenamiento en caché, consulte Almacenamiento en caché a continuación.

   • Si falla la autenticación, el demonio ldap-auth envía el código HTTP401 a NGINX Plus. NGINX Plus reenvía la solicitud al demonio backend nuevamente (como en el Paso 3) y el proceso se repite.

Instalación de los componentes

El archivo de configuración de NGINX Plus distribuido con la implementación de referencia, nginx-ldap-auth.conf , configura todos los componentes excepto el servidor LDAP (es decir, NGINX Plus, el cliente, el demonio ldap-auth y el demonio backend) para que se ejecuten en el mismo host, lo cual es adecuado para fines de prueba. El servidor LDAP también puede ejecutarse en ese host durante la prueba.

En una implementación real, la aplicação backend y el servidor de autenticación normalmente se ejecutan en un host separado, con NGINX Plus en un tercer host. El demonio ldap-auth no consume muchos recursos en la mayoría de las situaciones, por lo que puede ejecutarse en el host NGINX Plus o en otro host de su elección.

1. Crea un clon del repositorio de GitHub .

2. Si NGINX Plus aún no se está ejecutando, instálelo según las instrucciones de su sistema operativo.

3. Si aún no hay un servidor LDAP en ejecución, instale y configure uno. De forma predeterminada, el demonio ldap‑auth se comunica con OpenLDAP, pero también son compatibles Microsoft Windows Active Directory 2003 y 2012.

   Si está utilizando el servidor LDAP solo para probar la implementación de referencia, puede usar la imagen Docker del servidor OpenLDAP que está disponible en GitHub, o puede configurar un servidor usando instrucciones como Cómo instalar y configurar OpenLDAP y phpLDAPadmin en Ubuntu 16.04 .

   Tome nota de los valores que configure para el DN base, el DN de enlace y la contraseña de enlace. Los colocará en el archivo de configuración de NGINX en Configuración de la implementación de referencia .

4. En el host donde se ejecutará el demonio ldap‑auth, instale el siguiente software adicional. Recomendamos utilizar las versiones que se distribuyen con el sistema operativo, en lugar de descargar el software de un repositorio de código abierto.

   • Versión 2 de Python. La versión 3 no es compatible.
   • El módulo LDAP de Python, python‑ldap (creado por el proyecto de código abierto python-ldap.org ).

5. Copie los siguientes archivos desde su clon del repositorio a los hosts indicados:

   • nginx-ldap-auth.conf : archivo de configuración de NGINX Plus que incluye el conjunto mínimo de directivas para probar la implementación de referencia. Instalar en el host NGINX Plus (en el directorio /etc/nginx/conf.d si se utiliza el esquema de configuración convencional). Para evitar conflictos de configuración, recuerde mover o cambiar el nombre de los archivos de configuración predeterminados instalados con NGINX Plus.
   • nginx-ldap-auth-daemon.py – Código Python para el demonio ldap‑auth. Instalar en el host de su elección.
   • nginx-ldap-auth-daemon-ctl.sh – Ejemplo de script de shell para iniciar y detener el demonio. Instalar en el mismo host que el demonio ldap‑auth.
   • backend-sample-app.py – Código Python para el demonio que durante las pruebas reemplaza a un servidor de aplicação backend. Instalar en el host de su elección.

6. Modifique el archivo de configuración de NGINX Plus como se describe en Configuración de la implementación de referencia a continuación. Después de realizar los cambios, ejecute el comando nginx -t para verificar que el archivo sea sintácticamente válido.

   root# nginx -t nginx: la sintaxis del archivo de configuración /etc/nginx/nginx.conf es correcta nginx: la prueba del archivo de configuración /etc/nginx/nginx.conf es exitosa
   

7. Inicie NGINX Plus. Si NGINX Plus ya está ejecutándose, ejecute el siguiente comando para recargar el archivo de configuración:

   raíz# nginx -s recargar
   

8. Ejecute los siguientes comandos en los hosts apropiados para iniciar el demonio ldap‑auth y el demonio backend.

   raíz# nginx-ldap-auth-daemon-ctl.sh inicio raíz# python backend-sample-app.py
   

9. Utilice un navegador web para acceder a http:// nginx-server-address :8081 . Verificar que el navegador presente el formulario de autenticación. Después de completar el formulario y enviarlo, verifique que el servidor devuelva la respuesta esperada a las credenciales válidas. Como se señaló anteriormente, el demonio backend devuelve el siguiente texto:

      ¡Hola Mundo! URL solicitada: URL
   

Configuración de la implementación de referencia

Realice los siguientes cambios en el archivo nginx-ldap-auth.conf . Algunos son obligatorios y otros opcionales, según se indique.

Configuración del servidor LDAP

Tal como se implementa en nginx-ldap-auth-daemon.py , el demonio ldap‑auth se comunica con un servidor OpenLDAP, pasando parámetros para especificar qué cuenta de usuario autenticar. Para eliminar la necesidad de modificar el código Python, el archivo nginx-ldap-auth.conf contiene directivas proxy_set_header que establecen valores en el encabezado HTTP que luego se utilizan para establecer los parámetros. La siguiente tabla asigna los parámetros y encabezados.

• (Obligatorio) En las siguientes directivas, reemplace los valores en negrita con los valores correctos para su implementación del servidor LDAP. Tenga en cuenta en particular que el archivo nginx-ldap-auth.conf utiliza el puerto conocido para LDAPS, 636. Si cambia el puerto a 389 (el puerto conocido para LDAP) u otro puerto LDAP, recuerde también cambiar el nombre del protocolo de ldaps a ldap .

  # URL y puerto para conectarse al servidor LDAP proxy_set_header X-Ldap-URL " ldaps :// example.com :636 "; # DN base proxy_set_header X-Ldap-BaseDN " cn=Users,dc=test,dc=local "; # DN de enlace proxy_set_header X-Ldap-BindDN " cn=root,dc=test,dc=local "; # Contraseña de enlace proxy_set_header X-Ldap-BindPass " secreto ";
  

• (Obligatorio si se utiliza Active Directory en lugar de OpenLDAP) Descomente la siguiente directiva como se muestra:

  proxy_set_header X-Ldap-Template "(SAMAccountName=%(nombre de usuario)s)";
  

• (Opcional) La implementación de referencia utiliza autenticación basada en cookies. Si utiliza la autenticación básica HTTP, comente las siguientes directivas como se muestra:

  # proxy_set_header X-CookieName "nginxauth"; # proxy_set_header Cookie nginxauth=$cookie_nginxauth;
  

• (Opcional) Si desea cambiar el valor del parámetro de plantilla que el demonio ldap‑auth pasa al servidor OpenLDAP de manera predeterminada, descomente la siguiente directiva como se muestra y cambie el valor:

  proxy_set_header X-Ldap-Template " (cn=%(nombre de usuario)s) ";
  

• (Opcional) Si desea cambiar el nombre del reino del valor predeterminado ( Restringido ), descomente y cambie la siguiente directiva:

  proxy_set_header X-Ldap-Realm " Restringido ";
  

Dirección IP para el demonio backend

Si el demonio de backend no se ejecuta en el mismo host que NGINX Plus, cambie su dirección IP en el bloque de configuración ascendente :

servidor backend ascendente { servidor127.0.0.1 :9000; }

Dirección IP para el demonio ldap-auth

Si el demonio ldap‑auth no se ejecuta en el mismo host que NGINX Plus, cambie la dirección IP en esta directiva proxy_pass :

ubicación = /auth-proxy { contraseña_proxy http://127.0.0.1 :8888; # ... }

Dirección IP y puerto en el que escucha NGINX

Si el cliente no se ejecuta en el mismo host que NGINX Plus, cambie la dirección IP en esta directiva de escucha (o elimine la dirección por completo para aceptar tráfico de cualquier cliente). También puedes cambiar el puerto en el que NGINX escucha desde 8081 si lo deseas:

servidor { escuchar127.0.0.1 :8081 ; # ... }

Almacenamiento en caché

El archivo nginx-ldap-auth.conf permite el almacenamiento en caché de datos y credenciales. Opcionalmente, puede cambiar la siguiente configuración:

• La directiva proxy_cache_path en el bloque de configuración http crea un directorio de disco local llamado cache y asigna 10 MB en memoria compartida para una zona llamada auth_cache , donde se almacenan los metadatos.

  ruta_caché_proxy caché/ zona_claves= caché_de_autenticación : 10m ;
  

  Si cambia el nombre de la zona de memoria compartida, también debe cambiarlo en la directiva proxy_cache (en el bloque de ubicación que dirige el tráfico al demonio ldap‑auth).

  ubicación = /auth-proxy { proxy_cache auth_cache ; # ... }
  

• La directiva proxy_cache_valid (en el mismo bloque de ubicación que proxy_cache ) especifica que las respuestas almacenadas en caché marcadas con el código HTTP200 o403 son válidos por 10 minutos.

  ubicación = /auth-proxy { proxy_cache_valid 200 403 10m ; # ... }
  

Para deshabilitar el almacenamiento en caché, comente estas tres directivas más la directiva proxy_cache_key .

Personalización del sistema de autenticación

Como se mencionó anteriormente, puede utilizar el demonio ldap‑auth como modelo para su propia aplicação que acepta solicitudes del módulo http_auth_request. Si escribe una aplicación en Python para comunicarse con un tipo de servidor de autenticación diferente (no LDAP), escriba una nueva clase de controlador de autenticación para reemplazar LDAPAuthHandler en el script nginx-ldap-auth-daemon.py .

Una nota sobre seguridad

El demonio de backend utiliza codificación Base64 en el nombre de usuario y la contraseña en la cookie. Base64 es una forma muy débil de codificación, lo que hace que las credenciales sean vulnerables a la extracción y al uso indebido. Para que la autenticación tenga una finalidad real, es necesario utilizar un cifrado más sofisticado en su aplicação backend.