Configurar NGINX Plus para SSO SAML con Microsoft Entra ID

Para mejorar la seguridad y la experiencia del usuario, F5 NGINX Plus (R29+) ahora tiene soporte para Security Assertion Markup Language (SAML). SAML, un protocolo bien establecido que proporciona inicio de sesión único (SSO) a aplicações web, permite que un proveedor de identidad (IdP) autentique a los usuarios para acceder a un recurso y luego pasa esa información a un proveedor de servicios (SP) para su autorización.

En esta publicación de blog, cubrimos paso a paso cómo integrar NGINX con Microsoft Entra ID , anteriormente conocido como Azure Active Directory (Azure AD), mediante una aplicação web que no admite SAML de forma nativa. También cubrimos cómo implementar SSO para la aplicação e integrarlo con el ecosistema de Microsoft Entra ID. Si sigue el tutorial, también aprenderá cómo NGINX puede extraer reclamos de una afirmación SAML (incluido UPN, nombre, apellido y membresías de grupo) y luego pasarlos a la aplicação a través de encabezados HTTP.

El tutorial incluye tres pasos:

1. Configuración de Microsoft Entra ID como IdP
2. Configuración de los ajustes de SAML y NGINX Plus como proxy inverso
3. Probando la configuración

Para completar este tutorial, necesitarás:

• NGINX Plus (R29+), que puedes obtener como prueba gratuita de 30 días
• Una cuenta de Microsoft Entra ID gratuita o empresarial
• Un certificado SSL/TLS válido instalado en el servidor NGINX Plus (este tutorial utiliza dev.sports.com.crt y dev.sports.com.key )
• Para verificar las afirmaciones SAML, lo cual se puede hacer descargando el certificado público demonginx.cer del IdP

Nota : Este tutorial no se aplica a las implementaciones de código abierto de NGINX porque el almacén de clave-valor es exclusivo de NGINX Plus.

Uso de NGINX Plus como proveedor de servicios SAML

En esta configuración, NGINX Plus actúa como un SP SAML y puede participar en una implementación de SSO con un IdP SAML, que se comunica indirectamente con NGINX Plus a través del agente de usuario.

El siguiente diagrama ilustra el flujo del proceso SSO, con iniciación de SP y enlaces POST para solicitud y respuesta. Es importante señalar nuevamente que este canal de comunicación no es directo y se gestiona a través del Agente de Usuario.

Figura 1: SSO iniciado por SAML SP con enlaces POST para AuthnRequest y Response

Paso 1: Configurar Microsoft Entra ID como proveedor de identidad

Para acceder a su portal de administración de ID de Microsoft Entra, inicie sesión y navegue al panel de la izquierda. Seleccione Microsoft Entra ID y luego haga clic en el título del directorio que requiere configuración de SSO. Una vez seleccionado, elija Aplicações empresariales .

Figura 2: Selección de aplicações empresariales en el portal de gestión

Para crear una aplicação, haga clic en el botón Nueva aplicação en la parte superior del portal. En este ejemplo, creamos una aplicação llamada demonginx .

Figura 3: Creación de una nueva aplicação en Microsoft Entra ID

Después de ser redirigido a la aplicação recién creada Descripción general , vaya a Primeros pasos a través del menú de la izquierda y haga clic en Inicio de sesión único en Administrar . Luego, seleccione SAML como método de inicio de sesión único .

Figura 4: Uso de la sección SSO para iniciar la configuración de SAML

Para configurar el inicio de sesión único (SSO) en su aplicação empresarial, debe registrar NGINX Plus como proveedor de servicios (SP) en Microsoft Entra ID. Para ello, haga clic en el icono de lápiz junto a Editar en la configuración básica de SAML , como se muestra en la Figura 5.

Agregue los siguientes valores y luego haga clic en Guardar :

• Identificador (ID de entidad) : https://dev.sports.com
• URL de respuesta (URL del servicio de atención al consumidor de afirmaciones) : https://dev.sports.com/saml/acs
• URL de inicio de sesión : https://dev.sports.com
• URL de cierre de sesión (opcional) : https://dev.sports.com/saml/sls

El uso de certificados de verificación es opcional. Al habilitar esta configuración, se deben abordar dos opciones de configuración en NGINX:

1. Para verificar la firma con una clave pública, debe establecer $saml_sp_sign_authn en verdadero . Esto le indica al SP que firme la AuthnRequest enviada al IdP.
2. Proporcione la ruta a la clave privada que se utilizará para esta firma configurando $saml_sp_signing_key . Asegúrese de cargar el certificado de clave pública correspondiente a Microsoft Entra ID para la verificación de la firma.

Nota : En esta demostración, se han modificado los atributos y las reclamaciones, y se agregan nuevos atributos SAML. Estos atributos SAML son enviados por el IdP. Asegúrese de que su configuración de NGINX esté configurada para recibir y procesar correctamente estos atributos. Puede verificar y ajustar la configuración relacionada en el repositorio de GitHub de NGINX .

Descargue el certificado IdP (sin procesar) de Microsoft Entra ID y guárdelo en su instancia NGINX Plus.

Figura 5: Descargar el certificado IdP (sin procesar) de Microsoft Entra ID

Figura 6: Agregar un nuevo usuario o grupo

En Microsoft Entra ID, puede otorgar acceso a las aplicações de su empresa habilitadas para SSO agregando o asignando usuarios y grupos.

En el menú de la izquierda, haga clic en Usuario y grupos y luego en el botón superior Agregar usuario/grupo .

Paso 2: Configurar los ajustes de SAML y NGINX Plus como proxy inverso

Asegúrese de tener los certificados necesarios antes de configurar archivos en su NGINX Plus SP:

• Certificados para finalizar la sesión TLS ( dev.sports.com.crt y dev.sports.com.key )
• Certificado descargado de Microsoft Entra ID para la verificación de firma de IdP ( demonginx.cer )

Nota : Los certificados deben estar en formato SPKI.

Para comenzar este paso, descargue el certificado IdP de Microsoft Entra ID para la verificación de la firma. Luego, convierte el formato PEM al formato DER:

En caso de que desee verificar las afirmaciones de SAML SP, se recomienda utilizar claves públicas/privadas que sean diferentes de las utilizadas para la terminación TLS.

Extraiga el certificado de clave pública en formato SPKI:

Edite el archivo frontend.conf para actualizar estos elementos:

• ssl_certificate – Actualización para incluir la ruta del certificado TLS.
• ssl_certificate_key – Actualización para incluir la ruta de la clave privada TLS.

En la implementación de producción, puede utilizar diferentes destinos de back-end según los requisitos comerciales. En este ejemplo, el backend proporciona una respuesta personalizada:

Hemos modificado los atributos y las notificaciones en Microsoft Entra ID agregando nuevas notificaciones para el correo del usuario y el objectid . Estas actualizaciones le permiten ofrecer una respuesta más personalizada y adaptada a su aplicação, lo que se traduce en una mejor experiencia de usuario.

Figura 7: Atributos y notificaciones modificados en Microsoft Entra ID

El siguiente paso es configurar NGINX, que redirigirá el tráfico a la aplicação backend. En esta demostración, la aplicação SAML backend está disponible públicamente en https://dev.sports.com .

Edite su archivo frontend.conf :

# Este es el archivo frontend.conf
# Esta es la aplicação backend que estamos protegiendo con SAML SSO
aguas arriba my_backend {
zona my_backend 64k;
servidor dev.sports.com;
}

# Formato de registro personalizado para incluir el asunto 'NameID' en el campo REMOTE_USER
formato de registro saml_sso '$dirección_remota - $id_nombre_saml [$tiempo_local] "$solicitud" "$host" '
'$estado $body_bytes_sent "$http_referer"'
'"$http_user_agent" "$http_x_reenviado_para"';

# El servidor frontend: proxy inverso con autenticación SSO SAML
#
servidor {
# Ubicaciones funcionales que implementan la compatibilidad con SSO SAML
incluir conf.d/saml_sp.server_conf;


# Reducir el nivel de gravedad según sea necesario
error_log /var/log/nginx/error.log depuración;
escuchar 443 ssl;
certificado_ssl /home/ubuntu/dev.sports.com.crt;
clave de certificado ssl /home/ubuntu/dev.sports.com.key;
ssl_session_cache compartido:SSL:5m;


ubicación / {
# Cuando un usuario no está autenticado (es decir, "saml_access_granted."
# variable no está establecida en "1"), se genera un error HTTP 401 No autorizado
# devuelto, que es manejado por la ubicación nombrada @do_samlsp_flow.
error_pagina 401 = @do_samlsp_flow;

si ($saml_access_granted != "1") {
devolver 401;
}

# Los usuarios autenticados exitosamente son redirigidos al backend,
# con el atributo NameID pasado como encabezado HTTP
proxy_set_header mail $saml_attrib_mail; # ID de Microsoft Entra usuario.mail
proxy_set_header objectid $saml_attrib_objectid; # ID de objeto de Microsoft Entra
registro de acceso /var/log/nginx/access.log saml_sso;
proxy_pass <a href="http://my_backend;">http://mi_backend;</a>
proxy_set_header Host dev.sports.com;
devolver 200 "Bienvenido a la página de la aplicação \n Mi objectid es $http_objectid\n Mi correo electrónico es $http_mail\n";
tipo predeterminado texto/sin formato;

}
}
# vim: sintaxis=nginx         

Para que los atributos saml_attrib_mail y saml_attrib_objectid se reflejen en las configuraciones de NGINX, actualice la parte del almacén de clave-valor de saml_sp_configuration.conf de la siguiente manera:

keyval_zone zona=saml_attrib_mail:1M estado=/var/lib/nginx/state/saml_attrib_email.json tiempo de espera=1h; 
keyval $cookie_auth_token $saml_attrib_mail zona=saml_attrib_mail; 

keyval_zone zona=saml_attrib_objectid:1M estado=/var/lib/nginx/state/saml_attrib_objectid.json tiempo de espera=1h; 
keyval $cookie_auth_token $saml_attrib_objectid zona=saml_attrib_objectid; 

A continuación, configure el archivo de configuración de SSO SAML. Este archivo contiene las configuraciones principales para el SP y el IdP. Para personalizarlo según su configuración específica de SP e IdP, debe ajustar los múltiples bloques map{} incluidos en el archivo.

Esta tabla proporciona descripciones de las variables dentro de saml_sp_configuration.conf :

El código siguiente muestra los valores editados solo para este caso de uso en saml_sp_configuration.conf.

Nota : Asegúrese de que las partes restantes del archivo de configuración aún aparezcan en el archivo (por ejemplo, los almacenes de clave-valor). Asegúrese también de ajustar correctamente las variables dentro del archivo saml_sp_configuration.conf en función de su implementación.

 # Configuración de SSO SAML

map $host $saml_sp_entity_id { 
# Identificador único que identifica al SP ante el IdP. 
# Debe ser una URL o una URN. 
default "https://dev.sports.com"; 
} 

map $host $saml_sp_acs_url { 
# La URL del ACS, un punto final en el SP al que el IdP
# redirigirá con su respuesta de autenticación. 
# Debe coincidir con la ubicación del ACS definida en el archivo "saml_sp.serer_conf". 
default "https://dev.sports.com/saml/acs"; 
} 

map $host $saml_sp_request_binding { 
# Se refiere al método mediante el cual se envía una solicitud de autenticación desde el SP a un IdP durante el proceso de inicio de sesión único (SSO). 
# Solo se permiten los métodos HTTP-POST o HTTP-Redirect.
predeterminado 'HTTP-POST'; 
} 

map $host $saml_sp_sign_authn { 
# Indica si el SP debe firmar la AuthnRequest enviada al IdP. 
predeterminado "false"; 
} 

map $host $saml_sp_decryption_key { 
# Especifica la clave privada que el SP utiliza para descifrar la aserción cifrada
# o el NameID del IdP. 
predeterminado ""; 
} 

map $host $saml_sp_force_authn { 
# Indica si el SP debe forzar la reautenticación del usuario por parte del IdP. 
predeterminado "false"; 
} 

map $host $saml_sp_nameid_format { 
# Indica el formato deseado del identificador de nombre en la aserción SAML
# generada por el IdP. Consulte la sección 8.3 de la especificación SAML 2.0 Core (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) para ver la lista de formatos de NameID permitidos.

predeterminado: "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified";
}

map $host $saml_sp_relay_state {

URL relativa o absoluta a la que el SP debe redirigir

tras iniciar sesión correctamente.

predeterminado: "";
}

map $host $saml_sp_want_signed_response {

Si el SP desea que la respuesta SAML del IdP

esté firmada digitalmente.

predeterminado: "false"; } 

map $host $saml_sp_want_signed_assertion { 
# Si el SP desea que la aserción SAML del IdP
# esté firmada digitalmente. 

predeterminado "true"; 
} 

map $host $saml_sp_want_encrypted_assertion { 
# Si el SP desea que la aserción SAML del IdP
# esté cifrada. 

predeterminado "false"; 
} 

map $host $saml_idp_entity_id { 
# Identificador único que identifica al IdP ante el SP. 
# Debe ser una URL o una URN. 

predeterminado "https://sts.windows.net/8807dced-9637-4205-a520-423077750c60/"; } 

map $host $saml_idp_sso_url { 
# Punto final del proveedor de identidad (IdP) al que el proveedor de servicios (SP) enviará la solicitud de autenticación SAML para iniciar
# un proceso de autenticación. 

predeterminado: "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_idp_verification_certificate { 
# Archivo de certificado que se usará para verificar la firma digital
# en la respuesta SAML, la solicitud de cierre de sesión o la respuesta de cierre de sesión recibida del IdP. 
# Debe ser una clave pública en formato PKCS#1. Consulte la documentación sobre cómo convertir X.509 PEM a formato DER.

Default "/etc/nginx/conf.d/demonginx.spki";
}

######### Cierre de sesión único (SLO) #########

map $host $saml_sp_slo_url {

# Punto final del SP al que el IdP enviará la SAML LogoutRequest para iniciar un proceso de cierre de sesión o la LogoutResponse para confirmarlo.

Default "https://dev.sports.com/saml/sls";
}

map $host $saml_sp_slo_binding {

# Se refiere al método mediante el cual el SP envía una LogoutRequest o una LogoutResponse
# desde el SP a un IdP durante el proceso de cierre de sesión único (SLO). # Solo se permiten los métodos HTTP-POST o HTTP-Redirect. 

predeterminado: 'HTTP-POST'; }

map $host $saml_sp_sign_slo {

# Si el SP debe firmar la LogoutRequest o la LogoutResponse enviadas al IdP.

predeterminado: "false"; }

map $host $saml_idp_slo_url {
# Punto final del IdP al que el SP enviará la LogoutRequest para iniciar un proceso de cierre de sesión o la LogoutResponse para confirmarlo.


Si no se configura, la función de cierre de sesión único (SLO) de SAML está deshabilitada y las solicitudes a la ubicación de cierre de sesión provocarán la finalización de la sesión del usuario y una redirección a la página de inicio de cierre de sesión. predeterminado "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; }

map $host $saml_sp_want_signed_slo {

# Si el SP desea que la SAML LogoutRequest o la LogoutResponse del IdP estén firmadas digitalmente.

predeterminado "true"; }

map $host $saml_logout_landing_page {

# A dónde redirigir al usuario después de solicitar la ubicación de cierre de sesión. Esto se puede reemplazar con una página de cierre de sesión personalizada o una URL completa.

predeterminado "/_logout"; # Página de cierre de sesión simple e integrada
} 

map $proto $saml_cookie_flags { 
http "Path=/; SameSite=lax;"; # Para pruebas HTTP/texto plano 
https "Path=/; SameSite=lax; HttpOnly; Secure;"; # Recomendación de producción 
} 

map $http_x_forwarded_port $redirect_base { 
"" $proto://$host:$server_port; 
predeterminado $proto://$host:$http_x_forwarded_port; 
} 

map $http_x_forwarded_proto $proto { 
"" $scheme; 
predeterminado $http_x_forwarded_proto; } 
# CONFIGURACIÓN AVANZADA DEBAJO DE ESTA LÍNEA 
# Configuración avanzada adicional (contexto del servidor) en saml_sp.server_conf 

######## Zonas de memoria compartida que almacenan las bases de datos clave-valor relacionadas con SAML 

# Zona para almacenar los identificadores (ID) de los mensajes AuthnRequest y LogoutRequest 
# para evitar ataques de repetición. (OBLIGATORIO)
# El tiempo de espera determina cuánto tiempo espera el SP una respuesta del IDP, es decir, cuánto puede tardar el proceso de autenticación del usuario.

keyval_zone zone=saml_request_id:1M state=/var/lib/nginx/state/saml_request_id.json timeout=5m;

# Zona para almacenar los identificadores (ID) de los mensajes de respuesta SAML para evitar ataques de repetición. (OBLIGATORIO)
# El tiempo de espera determina cuánto tiempo el SP conserva los ID para evitar su reutilización.

keyval_zone zone=saml_response_id:1M state=/var/lib/nginx/state/saml_response_id.json timeout=1h;

# Zona para almacenar la información de acceso a la sesión SAML. (OBLIGATORIO)
# El tiempo de espera determina cuánto tiempo el SP conserva la decisión de acceso a la sesión (duración de la sesión).

keyval_zone zone=saml_session_access:1M state=/var/lib/nginx/state/saml_session_access.json timeout=1h;

# Zona para almacenar valores de NameID de SAML. (OBLIGATORIO)
# El tiempo de espera determina durante cuánto tiempo el SP conserva los valores de NameID. Debe ser igual a la duración de la sesión.
keyval_zone zone=saml_name_id:1M state=/var/lib/nginx/state/saml_name_id.json timeout=1h;

# Zona para almacenar valores en formato SAML NameID. (OBLIGATORIO)
# El tiempo de espera determina durante cuánto tiempo el SP conserva los valores del formato NameID. Debe ser igual a la duración de la sesión.
keyval_zone zone=saml_name_id_format:1M state=/var/lib/nginx/state/saml_name_id_format.json timeout=1h; 

# Zona para almacenar valores de SAML SessionIndex. (OBLIGATORIO)
# El tiempo de espera determina durante cuánto tiempo el SP conserva los valores de SessionIndex. Debe ser igual a la duración de la sesión.
keyval_zone zone=saml_session_index:1M state=/var/lib/nginx/state/saml_session_index.json timeout=1h; 

# Zona para almacenar valores SAML AuthnContextClassRef. (OBLIGATORIO)
# El tiempo de espera determina durante cuánto tiempo el SP conserva los valores de AuthnContextClassRef. Debe ser igual a la duración de la sesión.
keyval_zone zone=saml_authn_context_class_ref:1M state=/var/lib/nginx/state/saml_authn_context_class_ref.json timeout=1h; 

# Zonas para almacenar valores de atributos SAML. (OPCIONAL)
# El tiempo de espera determina durante cuánto tiempo el SP conserva los valores de los atributos. Debe ser igual a la duración de la sesión.
keyval_zone zone=saml_attrib_uid:1M state=/var/lib/nginx/state/saml_attrib_uid.json timeout=1h;
keyval_zone zone=saml_attrib_name:1M state=/var/lib/nginx/state/saml_attrib_name.json timeout=1h;
keyval_zone zone=saml_attrib_memberOf:1M state=/var/lib/nginx/state/saml_attrib_memberOf.json timeout=1h;

######## Variables relacionadas con SAML cuyo valor se busca mediante la clave (cookie de sesión) en la base de datos clave-valor.

# Obligatorio:
keyval $saml_request_id $saml_request_redeemed zone=saml_request_id; # ID de solicitud SAML
keyval $saml_response_id $saml_response_redeemed zone=saml_response_id; # ID de respuesta SAML
keyval $cookie_auth_token $saml_access_granted zone=saml_session_access; # Decisión de acceso SAML
keyval $cookie_auth_token $saml_name_id zone=saml_name_id; # ID de nombre SAML
keyval $cookie_auth_token $saml_name_id_format zone=saml_name_id_format; # Formato del ID de nombre SAML
keyval $cookie_auth_token $saml_session_index zone=saml_session_index; # Índice de sesión SAML
keyval $cookie_auth_token $saml_authn_context_class_ref zone=saml_authn_context_class_ref; # SAML AuthnContextClassRef

# Opcional: 
keyval $cookie_auth_token $saml_attrib_uid zone=saml_attrib_uid; 
keyval $cookie_auth_token $saml_attrib_name zone=saml_attrib_name; 
keyval $cookie_auth_token $saml_attrib_memberOf zone=saml_attrib_memberOf; 

keyval_zone zone=saml_attrib_mail:1M state=/var/lib/nginx/state/saml_attrib_mail.json timeout=1h; 
keyval $cookie_auth_token $saml_attrib_mail zone=saml_attrib_mail; 

keyval $cookie_auth_token $saml_attrib_objectid zone=saml_attrib_objectid; 

keyval_zone zone=saml_attrib_objectid:1M state=/var/lib/nginx/state/saml_attrib_objectid.json timeout=1h; 

######## Importa un módulo que implementa la funcionalidad SAML SSO y SLO. 
js_import samlsp from conf.d/saml_sp.js; 

Paso 3: Probando la configuración

Se requieren dos partes para probar la configuración:

1. Verificación del flujo SAML
2. Prueba de la funcionalidad de cierre de sesión iniciado por SP

Verificación del flujo SAML

Después de configurar el SAML SP usando NGINX Plus y el IdP usando Microsoft Entra ID, es crucial validar el flujo SAML. Este proceso de validación garantiza que la autenticación del usuario a través del IdP sea exitosa y que se conceda el acceso a los recursos protegidos por SP.

Para verificar el flujo SAML iniciado por SP, abra su navegador preferido y escriba https://dev.sports.com en la barra de direcciones. Esto le dirigirá a la página de inicio de sesión de IdP.

Figura 8: La página de inicio de sesión del IdP

Ingrese las credenciales de un usuario que esté configurado en la página de inicio de sesión del IdP. El IdP autenticará al usuario al enviar.

Figura 9: Ingresar las credenciales del usuario configurado

Al establecer exitosamente una sesión, se le concederá al usuario acceso al recurso protegido solicitado previamente. Posteriormente dicho recurso se mostrará en el navegador del usuario.

Figura 10: La página de la aplicação cargada correctamente

Se puede obtener información valiosa sobre el flujo SAML verificando los registros de SP e IdP. En el lado SP (NGINX Plus), asegúrese de que las cookies auth_token estén configuradas correctamente. En el lado del IdP (ID de Microsoft Entra), asegúrese de que el proceso de autenticación se complete sin errores y que la afirmación SAML se envíe al SP.

El archivo access.log de NGINX debería verse así:

127.0.0.1 - - [14/Aug/2023:21:25:49 +0000] "GET / HTTP/1.0" 200 127 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, como Gecko) Versión/16.1 Safari/605.1.15" "-" 

99.187.244.63 - Akash Ananthanarayanan [14/ago/2023:21:25:49 +0000] "GET / HTTP/1.1" "dev.sports.com" 200 127 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, como Gecko) Versión/16.1 Safari/605.1.15" "- 

El archivo debug.log de NGINX se ve así:

14/08/2023 21:25:49 [información] 27513#27513: *399 js: Creación exitosa de la sesión _d4db9b93c415ee7b4e057a4bb195df6cd0be7e4d 

Prueba de la funcionalidad de cierre de sesión iniciado por SP

El cierre de sesión único (SLO) de SAML permite a los usuarios cerrar la sesión de todos los IdP y SP involucrados con una sola acción. NGINX Plus admite escenarios de cierre de sesión iniciados por SP y por IdP, lo que mejora la seguridad y la experiencia del usuario en entornos SSO. En este ejemplo, utilizamos un escenario de cierre de sesión iniciado por SP.

Figura 11: SLO iniciado por SAML SP con enlaces POST/redireccionamiento para LogoutRequest y LogoutResponse

Después de autenticar su sesión, cierre la sesión accediendo a la URL de cierre de sesión configurada en su SP. Por ejemplo, si ha configurado https://dev.sports.com/logout como la URL de cierre de sesión en NGINX Plus, ingrese esa URL en la barra de direcciones de su navegador.

Figura 12: Cerrar sesión exitosamente

Para garantizar un cierre de sesión seguro, el SP debe iniciar una solicitud SAML que luego es verificada y procesada por el IdP. Esta acción finaliza efectivamente la sesión del usuario y el IdP enviará una respuesta SAML para redirigir el navegador del usuario nuevamente al SP.

CONCLUSIÓN

¡Enhorabuena! NGINX Plus ahora puede funcionar como un SP SAML, brindando otra capa de seguridad y conveniencia al proceso de autenticación. Esta nueva capacidad es un importante paso adelante para NGINX Plus, convirtiéndola en una solución más sólida y versátil para las organizaciones que priorizan la seguridad y la eficiencia. 

Obtenga más información sobre el uso de SAML con NGINX Plus

Puede comenzar a utilizar SAML con NGINX Plus hoy mismo iniciando una prueba gratuita de 30 días de NGINX Plus . Esperamos que le resulte útil y agradecemos sus comentarios.

Más información sobre NGINX Plus con SAML está disponible en los recursos a continuación.

• Anunciamos NGINX Plus R29
• Compatibilidad con SAML en NGINX Plus como implementación de referencia en GitHub