Para reforzar la seguridad y mejorar la experiencia del usuario, F5 NGINX Plus (R29+) ahora es compatible con el lenguaje de marcado para confirmaciones de seguridad (SAML). SAML es un protocolo consolidado que proporciona inicio de sesión único (SSO) en aplicaciones web y permite que un proveedor de identidades (IdP) autentique a los usuarios para acceder a un recurso y, a continuación, transmita esa información a un proveedor de servicios (SP) para su autorización.
En esta entrada del blog, explicamos paso a paso cómo integrar NGINX con Microsoft Entra ID, anteriormente conocido como Azure Active Directory (Azure AD), mediante una aplicación web que no admite SAML de forma nativa. También explicamos cómo implementar el inicio de sesión único (SSO) para la aplicación e integrarla en el ecosistema de Microsoft Entra ID. Al seguir este tutorial, también aprenderá cómo NGINX puede extraer atributos de una aserción SAML (incluidos el UPN, el nombre, los apellidos y la pertenencia a grupos) y, a continuación, pasarlos a la aplicación mediante encabezados HTTP.
El tutorial consta de tres pasos:
- Configurar Microsoft Entra ID como proveedor de identidades (IdP)
- Configuración de los ajustes de SAML y de NGINX Plus como proxy inverso
- Probar la configuración
Para completar este tutorial, necesitas:
- NGINX Plus (R29+), que puedes obtener como prueba gratuita de 30 días
- Una cuenta gratuita o empresarial de Microsoft Entra ID
- Un certificado SSL/TLS válido instalado en el servidor NGINX Plus (en este tutorial se utilizan
dev.sports.com.crt and dev.sports.com.key) - Para verificar las aserciones SAML, puede descargar el certificado público
demonginx.cerdel IdP
Nota: Este tutorial no se aplica a las implementaciones de NGINX Open Source porque el almacén de pares 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 SP de SAML y puede participar en una implementación de SSO con un IdP de SAML, que se comunica indirectamente con NGINX Plus a través del agente de usuario.
El diagrama siguiente ilustra el flujo del proceso de SSO, con inicio por parte del SP y enlaces POST para la solicitud y la respuesta. Es fundamental recalcar que este canal de comunicación no es directo, sino que se gestiona a través del agente de usuario.
Figura 1: SSO de SAML iniciado por el SP con enlaces POST para AuthnRequest y Response
Paso 1: Configurar Microsoft Entra ID como proveedor de identidades
Para acceder al portal de administración de Microsoft Entra ID, inicia sesión y ve al panel de la izquierda. Selecciona Microsoft Entra ID y, a continuación, haz clic en el nombre del directorio en el que quieras configurar el SSO. Una vez seleccionado, elige Aplicaciones empresariales.

Figura 2: Selección de Aplicaciones empresariales en el portal de administración
Para crear una aplicación, haga clic en el botón «Nueva aplicación» situado en la parte superior del portal. En este ejemplo, hemos creado una aplicación llamada «demonginx».

Figura 3: Creación de una nueva aplicación en Microsoft Entra ID
Después de que se te redirija a la aplicación recién creada, ve a Información general, accede a Introducción desde el menú de la izquierda y haz clic en Inicio de sesión único en Administrar. A continuación, selecciona SAML como método de inicio de sesión único.

Figura 4: Uso de la sección de SSO para iniciar la configuración de SAML
Para configurar el SSO en su aplicación empresarial, debe registrar NGINX Plus como SP en Microsoft Entra ID. Para ello, haga clic en el icono del lápiz situado junto a «Editar» en «Configuración básica de SAML», como se muestra en la figura 5.
Añada los siguientes valores y, a continuación, haga clic en «Guardar»:
- Identificador (ID de entidad) – https://dev.sports.com
- URL de respuesta (URL del servicio de consumidor de aserciones) – 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 este ajuste, deben configurarse dos opciones en NGINX:
- Para verificar la firma con una clave pública, debe establecer
$saml_sp_sign_authnen true. Esto indica al SP que firme la AuthnRequest enviada al IdP. - 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 en Microsoft Entra ID para verificar la firma.
Nota: En esta demostración, se han modificado los atributos y las notificaciones, y se han añadido nuevos atributos SAML. El IdP envía estos atributos SAML. Asegúrese de que su configuración de NGINX esté preparada para recibir y procesar correctamente estos atributos. Puede comprobar y ajustar la configuración relacionada en el repositorio de NGINX en GitHub.
Descargue el certificado (sin procesar) del IdP desde Microsoft Entra ID y guárdelo en su instancia de NGINX Plus.

Figura 5: Descarga del certificado del IdP (sin procesar) desde Microsoft Entra ID

Figura 6: Adición de un nuevo usuario o grupo
En Microsoft Entra ID, puede conceder acceso a las aplicaciones de su empresa habilitadas para SSO añadiendo o asignando usuarios y grupos.
En el menú de la izquierda, haga clic en «Usuarios y grupos» y, a continuación, en el botón superior «Agregar usuario o grupo».
Paso 2: Configurar los ajustes de SAML y NGINX Plus como proxy inverso
Asegúrese de disponer de los certificados necesarios antes de configurar los archivos en su SP de NGINX Plus:
- Certificados para finalizar la sesión TLS (
dev.sports.com.crt y dev.sports.com.key) - Certificado descargado de Microsoft Entra ID para verificar la firma del IdP (
demonginx.cer)
Nota: Los certificados deben estar en formato SPKI.
Para comenzar este paso, descargue el certificado del IdP de Microsoft Entra ID para verificar la firma. A continuación, convierta el formato PEM a DER:
openssl x509 -in demonginx.cer -outform DER -out demonginx.der
Si desea verificar las aserciones del SP de SAML, se recomienda utilizar claves públicas/privadas distintas de las empleadas para la terminación TLS.
Extrae el certificado de clave pública en formato SPKI:
openssl x509 -inform DER -in demonginx.der -pubkey -noout > demonginx.spki
Edita el archivo frontend.conf para actualizar estos elementos:
ssl_certificate– Actualícelo para incluir la ruta del certificado TLS.ssl_certificate_key– Actualícelo para incluir la ruta de la clave privada TLS.
En un despliegue de producción, puede utilizar distintos destinos de backend en función de los requisitos empresariales. En este ejemplo, el backend proporciona una respuesta personalizada:
“Bienvenido a la página de la aplicaciónn Mi identificador de objeto es $http_objectidn Mi correo electrónico es $http_mailn”;
Hemos modificado los atributos y las notificaciones en Microsoft Entra ID añadiendo nuevas notificaciones para el correo electrónico y el identificador de objeto del usuario. Estas actualizaciones permiten ofrecer una respuesta más personalizada y adaptada en la aplicación, lo que mejora la experiencia del usuario.

Figura 7: Atributos y notificaciones modificados en Microsoft Entra ID
El siguiente paso es configurar NGINX, que actuará como proxy del tráfico hacia la aplicación de backend. En esta demostración, la aplicación SAML de backend está disponible públicamente en https://dev.sports.com.
Edita tu archivo «frontend.conf»:
# This is file frontend.conf
# This is the backend application we are protecting with SAML SSO
upstream my_backend {
zone my_backend 64k;
server dev.sports.com;
}
# Custom log format to include the 'NameID' subject in the REMOTE_USER field
log_format saml_sso '$remote_addr - $saml_name_id [$time_local] "$request" "$host" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
# The frontend server - reverse proxy with SAML SSO authentication
#
server {
# Functional locations implementing SAML SSO support
include conf.d/saml_sp.server_conf;
# Reduce severity level as required
error_log /var/log/nginx/error.log debug;
listen 443 ssl;
ssl_certificate /home/ubuntu/dev.sports.com.crt;
ssl_certificate_key /home/ubuntu/dev.sports.com.key;
ssl_session_cache shared:SSL:5m;
location / {
# When a user is not authenticated (i.e., the "saml_access_granted."
# variable is not set to "1"), an HTTP 401 Unauthorized error is
# returned, which is handled by the @do_samlsp_flow named location.
error_page 401 = @do_samlsp_flow;
if ($saml_access_granted != "1") {
return 401;
}
# Successfully authenticated users are proxied to the backend,
# with the NameID attribute passed as an HTTP header
proxy_set_header mail $saml_attrib_mail; # Microsoft Entra ID's user.mail
proxy_set_header objectid $saml_attrib_objectid; # Microsoft Entra ID's objectid
access_log /var/log/nginx/access.log saml_sso;
proxy_pass http://my_backend;
proxy_set_header Host dev.sports.com;
return 200 "Welcome to Application pagen My objectid is $http_objectidn My email is $http_mailn";
default_type text/plain;
}
}
# vim: syntax=nginx
Para que los atributos saml_attrib_mail y saml_attrib_ objectid se reflejen en las configuraciones de NGINX, actualice la sección del almacén de pares clave-valor de saml_sp_configuration.conf de la siguiente manera:
keyval_zone zone=saml_attrib_mail:1M state=/var/lib/nginx/state/saml_attrib_email.json timeout=1h;
keyval $cookie_auth_token $saml_attrib_mail zone=saml_attrib_mail;
keyval_zone zone=saml_attrib_objectid:1M state=/var/lib/nginx/state/saml_attrib_objectid.json timeout=1h;
keyval $cookie_auth_token $saml_attrib_objectid zone=saml_attrib_objectid;
A continuación, configure el archivo de configuración de SSO mediante SAML. Este archivo contiene las configuraciones principales del SP y el IdP. Para personalizarlo según la configuración específica de su SP e IdP, debe ajustar los distintos bloques map{} incluidos en el archivo.
Esta tabla proporciona descripciones de las variables incluidas en saml_sp_configuration.conf:
| Variable | Descripción |
|---|---|
saml_sp_entity_id | La URL que utilizan los usuarios para acceder a la aplicación. |
saml_sp_acs_url | La URL que utiliza el proveedor de servicios para recibir y procesar la respuesta SAML, extraer la identidad del usuario y, a continuación, conceder o denegar el acceso al recurso solicitado en función de la información proporcionada. |
saml_sp_sign_authn | Especifica si la solicitud SAML del SP al IdP debe estar firmada. La firma se realiza con la clave de firma del SP y es necesario cargar el certificado asociado en el IdP para verificarla. |
saml_sp_signing_key | La clave de firma que se utiliza para firmar la solicitud SAML del SP al IdP. Asegúrese de cargar el certificado asociado en el IdP para verificar la firma. |
saml_idp_entity_id | La identidad que se utiliza para definir el IdP. |
saml_idp_sso_url | El punto de conexión del IdP al que el SP envía la solicitud de aserción SAML para iniciar la solicitud de autenticación. |
saml_idp_verification_certificate | El certificado utilizado para verificar las aserciones SAML firmadas que se reciben del IdP. El IdP proporciona el certificado, que debe estar en formato SPKI. |
saml_sp_slo_url | El punto de conexión del SP al que el IdP envía la solicitud SAML LogoutRequest (al iniciar un proceso de cierre de sesión) o la respuesta LogoutResponse (al confirmar el cierre de sesión). |
saml_sp_sign_slo | Especifica si el SP debe firmar el mensaje SAML de cierre de sesión. |
saml_idp_slo_url | El punto de conexión del IdP al que el SP envía la solicitud LogoutRequest (al iniciar un proceso de cierre de sesión) o la respuesta LogoutResponse (al confirmar el cierre de sesión). |
saml_sp_want_signed_slo | Especifica si el SP de SAML requiere que la respuesta o la solicitud SAML de cierre de sesión del IdP esté firmada. |
El código siguiente muestra únicamente los valores modificados para este caso de uso en saml_sp_configuration.conf.
Nota: Asegúrese de que las demás partes del archivo de configuración sigan incluidas en él (por ejemplo, los almacenes de clave-valor). Asegúrese también de ajustar correctamente las variables del archivo saml_sp_configuration.conf en función de su implementación.
# SAML SSO configuration
map $host $saml_sp_entity_id {
# Unique identifier that identifies the SP to the IdP.
# Must be URL or URN.
default "https://dev.sports.com";
}
map $host $saml_sp_acs_url {
# The ACS URL, an endpoint on the SP where the IdP
# will redirect to with its authentication response.
# Must match the ACS location defined in the "saml_sp.serer_conf" file.
default "https://dev.sports.com/saml/acs";
}
map $host $saml_sp_request_binding {
# Refers to the method by which an authentication request is sent from
# the SP to an IdP during the Single Sign-On (SSO) process.
# Only HTTP-POST or HTTP-Redirect methods are allowed.
default 'HTTP-POST';
}
map $host $saml_sp_sign_authn {
# Whether the SP should sign the AuthnRequest sent to the IdP.
default "false";
}
map $host $saml_sp_decryption_key {
# Specifies the private key that the SP uses to decrypt encrypted assertion
# or NameID from the IdP.
default "";
}
map $host $saml_sp_force_authn {
# Whether the SP should force re-authentication of the user by the IdP.
default "false";
}
map $host $saml_sp_nameid_format {
# Indicates the desired format of the name identifier in the SAML assertion
# generated by the IdP. Check section 8.3 of the SAML 2.0 Core specification
# (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)
# for the list of allowed NameID Formats.
default "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified";
}
map $host $saml_sp_relay_state {
# Relative or absolute URL the SP should redirect to
# after successful sign on.
default "";
}
map $host $saml_sp_want_signed_response {
# Whether the SP wants the SAML Response from the IdP
# to be digitally signed.
default "false";
}
map $host $saml_sp_want_signed_assertion {
# Whether the SP wants the SAML Assertion from the IdP
# to be digitally signed.
default "true";
}
map $host $saml_sp_want_encrypted_assertion {
# Whether the SP wants the SAML Assertion from the IdP
# to be encrypted.
default "false";
}
map $host $saml_idp_entity_id {
# Unique identifier that identifies the IdP to the SP.
# Must be URL or URN.
default "https://sts.windows.net/8807dced-9637-4205-a520-423077750c60/";
}
map $host $saml_idp_sso_url {
# IdP endpoint that the SP will send the SAML AuthnRequest to initiate
# an authentication process.
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2";
}
map $host $saml_idp_verification_certificate {
# Certificate file that will be used to verify the digital signature
# on the SAML Response, LogoutRequest or LogoutResponse received from IdP.
# Must be public key in PKCS#1 format. See documentation on how to convert
# X.509 PEM to DER format.
default "/etc/nginx/conf.d/demonginx.spki";
}
######### Single Logout (SLO) #########
map $host $saml_sp_slo_url {
# SP endpoint that the IdP will send the SAML LogoutRequest to initiate
# a logout process or LogoutResponse to confirm the logout.
default "https://dev.sports.com/saml/sls";
}
map $host $saml_sp_slo_binding {
# Refers to the method by which a LogoutRequest or LogoutResponse
# is sent from the SP to an IdP during the Single Logout (SLO) process.
# Only HTTP-POST or HTTP-Redirect methods are allowed.
default 'HTTP-POST';
}
map $host $saml_sp_sign_slo {
# Whether the SP must sign the LogoutRequest or LogoutResponse
# sent to the IdP.
default "false";
}
map $host $saml_idp_slo_url {
# IdP endpoint that the SP will send the LogoutRequest to initiate
# a logout process or LogoutResponse to confirm the logout.
# If not set, the SAML Single Logout (SLO) feature is DISABLED and
# requests to the 'logout' location will result in the termination
# of the user session and a redirect to the logout landing page.
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2";
}
map $host $saml_sp_want_signed_slo {
# Whether the SP wants the SAML LogoutRequest or LogoutResponse from the IdP
# to be digitally signed.
default "true";
}
map $host $saml_logout_landing_page {
# Where to redirect user after requesting /logout location. This can be
# replaced with a custom logout page, or complete URL.
default "/_logout"; # Built-in, simple logout page
}
map $proto $saml_cookie_flags {
http "Path=/; SameSite=lax;"; # For HTTP/plaintext testing
https "Path=/; SameSite=lax; HttpOnly; Secure;"; # Production recommendation
}
map $http_x_forwarded_port $redirect_base {
"" $proto://$host:$server_port;
default $proto://$host:$http_x_forwarded_port;
}
map $http_x_forwarded_proto $proto {
"" $scheme;
default $http_x_forwarded_proto;
}
# ADVANCED CONFIGURATION BELOW THIS LINE
# Additional advanced configuration (server context) in saml_sp.server_conf
######### Shared memory zones that keep the SAML-related key-value databases
# Zone for storing AuthnRequest and LogoutRequest message identifiers (ID)
# to prevent replay attacks. (REQUIRED)
# Timeout determines how long the SP waits for a response from the IDP,
# i.e. how long the user authentication process can take.
keyval_zone zone=saml_request_id:1M state=/var/lib/nginx/state/saml_request_id.json timeout=5m;
# Zone for storing SAML Response message identifiers (ID) to prevent replay attacks. (REQUIRED)
# Timeout determines how long the SP keeps IDs to prevent reuse.
keyval_zone zone=saml_response_id:1M state=/var/lib/nginx/state/saml_response_id.json timeout=1h;
# Zone for storing SAML session access information. (REQUIRED)
# Timeout determines how long the SP keeps session access decision (the session lifetime).
keyval_zone zone=saml_session_access:1M state=/var/lib/nginx/state/saml_session_access.json timeout=1h;
# Zone for storing SAML NameID values. (REQUIRED)
# Timeout determines how long the SP keeps NameID values. Must be equal to session lifetime.
keyval_zone zone=saml_name_id:1M state=/var/lib/nginx/state/saml_name_id.json timeout=1h;
# Zone for storing SAML NameID format values. (REQUIRED)
# Timeout determines how long the SP keeps NameID format values. Must be equal to session lifetime.
keyval_zone zone=saml_name_id_format:1M state=/var/lib/nginx/state/saml_name_id_format.json timeout=1h;
# Zone for storing SAML SessionIndex values. (REQUIRED)
# Timeout determines how long the SP keeps SessionIndex values. Must be equal to session lifetime.
keyval_zone zone=saml_session_index:1M state=/var/lib/nginx/state/saml_session_index.json timeout=1h;
# Zone for storing SAML AuthnContextClassRef values. (REQUIRED)
# Timeout determines how long the SP keeps AuthnContextClassRef values. Must be equal to session lifetime.
keyval_zone zone=saml_authn_context_class_ref:1M state=/var/lib/nginx/state/saml_authn_context_class_ref.json timeout=1h;
# Zones for storing SAML attributes values. (OPTIONAL)
# Timeout determines how long the SP keeps attributes values. Must be equal to session lifetime.
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;
######### SAML-related variables whose value is looked up by the key (session cookie) in the key-value database.
# Required:
keyval $saml_request_id $saml_request_redeemed zone=saml_request_id; # SAML Request ID
keyval $saml_response_id $saml_response_redeemed zone=saml_response_id; # SAML Response ID
keyval $cookie_auth_token $saml_access_granted zone=saml_session_access; # SAML Access decision
keyval $cookie_auth_token $saml_name_id zone=saml_name_id; # SAML NameID
keyval $cookie_auth_token $saml_name_id_format zone=saml_name_id_format; # SAML NameIDFormat
keyval $cookie_auth_token $saml_session_index zone=saml_session_index; # SAML SessionIndex
keyval $cookie_auth_token $saml_authn_context_class_ref zone=saml_authn_context_class_ref; # SAML AuthnContextClassRef
# Optional:
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;
######### Imports a module that implements SAML SSO and SLO functionality
js_import samlsp from conf.d/saml_sp.js;
Paso 3: Probar la configuración
Se necesitan dos partes para probar la configuración:
- Verificación del flujo SAML
- Prueba de la funcionalidad de cierre de sesión iniciado por el SP
Verificación del flujo SAML
Después de configurar el SP de SAML mediante NGINX Plus y el IdP mediante Microsoft Entra ID, es fundamental validar el flujo de SAML. Este proceso de validación garantiza que la autenticación de los usuarios a través del IdP se realice correctamente y que se conceda acceso a los recursos protegidos por el SP.
Para verificar el flujo SAML iniciado por el SP, abra su navegador preferido e introduzca https://dev.sports.com en la barra de direcciones. Esto le redirigirá a la página de inicio de sesión del IdP.

Figura 8: Página de inicio de sesión del IdP
Introduzca las credenciales de un usuario configurado en la página de inicio de sesión del IdP. El IdP autenticará al usuario cuando envíe el formulario.

Figura 9: Introducción de las credenciales del usuario configurado
Una vez establecida correctamente la sesión, se concederá al usuario acceso al recurso protegido solicitado anteriormente. A continuación, dicho recurso se mostrará en el navegador del usuario.

Figura 10: Página de la aplicación cargada correctamente
Se puede obtener información valiosa sobre el flujo SAML consultando los registros del SP y del IdP. En el lado del SP (NGINX Plus), asegúrese de que las cookies auth_token estén configuradas correctamente. En el lado del IdP (Microsoft Entra ID), asegúrese de que el proceso de autenticación finalice sin errores y de que la aserción SAML se envíe al SP.
El archivo access.log de NGINX debería tener este aspecto:
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, like Gecko) Version/16.1 Safari/605.1.15" "-"
99.187.244.63 - Akash Ananthanarayanan [14/Aug/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, like Gecko) Version/16.1 Safari/605.1.15" "-
Mientras que el archivo debug.log de NGINX tiene este aspecto:
2023/08/14 21:25:49 [info] 27513#27513: *399 js: SAML SP success, creating session _d4db9b93c415ee7b4e057a4bb195df6cd0be7e4d
Prueba de la funcionalidad de cierre de sesión iniciada por el SP
El cierre de sesión único (SLO) de SAML permite a los usuarios cerrar sesión en todos los IdP y SP implicados con una sola acción. NGINX Plus admite escenarios de cierre de sesión iniciados por el SP y por el IdP, lo que mejora la seguridad y la experiencia del usuario en entornos de SSO. En este ejemplo, utilizamos un escenario de cierre de sesión iniciado por el SP.
Figura 11: SLO de SAML iniciado por el SP con enlaces POST/redirección para LogoutRequest y LogoutResponse
Después de autenticar la sesión, ciérrela accediendo a la URL de cierre de sesión configurada en su SP. Por ejemplo, si ha configurado https://dev.sports.com/logout como URL de cierre de sesión en NGINX Plus, introdúzcala en la barra de direcciones del navegador.

Figura 12: Cierre de sesión correcto
Para garantizar un cierre de sesión seguro, el SP debe iniciar una solicitud SAML que, a continuación, el IdP verificará y procesará. Esta acción finaliza de forma efectiva la sesión del usuario y, seguidamente, el IdP enviará una respuesta SAML para redirigir el navegador del usuario de vuelta al SP.
Conclusión
¡Enhorabuena! NGINX Plus ahora puede actuar como SP de SAML, lo que aporta una capa adicional de seguridad y comodidad al proceso de autenticación. Esta nueva capacidad supone un avance significativo para NGINX Plus y lo convierte en una solución más sólida y versátil para las organizaciones que priorizan la seguridad y la eficiencia.
Más información sobre el uso de SAML con NGINX Plus
Puede empezar a usar 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.
Encontrará más información sobre NGINX Plus con SAML en los siguientes recursos.
- Presentamos NGINX Plus R29
- Compatibilidad con SAML en NGINX Plus como implementación de referencia en GitHub
Sobre el autor

Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.