Aunque OIDC se usa cada vez más en las aplicaciones modernas, SAML 2.0 sigue siendo un estándar crítico en las integraciones de identidad corporativa y del sector público. Muchas organizaciones ejecutan sus directorios existentes detrás de AD FS, Entra ID, Okta, Ping, Auth0 o un gateway de federación mediante SAML. En el lado público, las federaciones de identidad nacionales y los servicios SaaS vinculados a ellas suelen estar construidos sobre SAML 2.0.
Por eso, para una aplicación nueva o modernizada, el enfoque correcto no es crear una base de datos de usuarios separada. La aplicación debe conectarse al proveedor de identidad en el que la organización ya confía. Para ello, la capa de acceso debe actuar como proveedor de servicios SAML 2.0: debe redirigir al usuario al IdP correcto, validar la respuesta SAML entrante, extraer la identidad de forma segura y convertirla en una sesión que la aplicación pueda usar.
Sin embargo, la integración SAML no es solo "toma el XML, lee al usuario, inicia sesión". Implementada mal, produce graves vulnerabilidades de seguridad. La firma de la respuesta SAML debe validarse correctamente, debe comprobarse qué parte está realmente firmada y deben bloquearse ataques como la eliminación de firma o la inyección de aserciones falsas. La ventana de validez, la restricción de audience, la información de issuer, el formato de NameID y los mapeos de atributos no deben solo leerse; deben aplicarse de forma estricta.
El lado operativo es igual de importante. La actualización del metadata del IdP, la rotación de certificados y claves de firma, el enrutamiento de IdP por tenant, las distintas reglas de mapeo para distintas aplicaciones y los flujos de Single Logout no son pequeños detalles que se añaden después. Son piezas fundamentales para que la federación SAML funcione de forma segura y sostenible.
Uno de los errores más comunes es incrustar una librería SAML separada en cada aplicación. Este enfoque distribuye la responsabilidad de la identidad a cada backend. Un cambio de IdP requiere actualizaciones separadas en numerosas aplicaciones. El MFA, el acceso condicional, la confianza del dispositivo, el comportamiento de cierre de sesión y los registros de auditoría se intentan resolver de nuevo para cada aplicación. El resultado no es identidad centralizada, sino un caos de identidad distribuida.
El lugar correcto es el borde de acceso. SAML debe terminarse en un único punto; debe gestionarse en la misma capa que la autenticación, el MFA, el acceso condicional, la confianza del dispositivo y el Backend SSO. Así, las aplicaciones no cargan con la complejidad del protocolo de federación; solo reciben una identidad verificada, limpia y confiable.
Gestionar SAML correctamente no es solo conectarse a un IdP. Es validar la confianza de identidad de la organización en un único punto, auditarla y trasladarla de forma segura a las aplicaciones.
Un único gateway de AAM termina SAML correctamente en el borde; el resto del motor de acceso se monta sobre él.
AuthnRequest firmado a la salida, validación completa de aserción a la entrada — firma, audience, ventana de validez, AudienceRestriction, formato de NameID. Se soportan ambos bindings HTTP-Redirect y HTTP-POST. El manejo de firmas sigue las reglas de conformidad SAML 2.0 existentes para neutralizar los ataques SAML conocidos.
Un único gateway de AAM puede enrutar distintas aplicaciones a distintos IdP y distintos tenants de la misma aplicación a distintos IdP de forma simultánea. La selección de IdP se hace por solicitud según el contexto de la aplicación — sin un gateway separado por IdP, sin selector de página de inicio de sesión manual para el usuario.
Las reglas de mapeo por IdP traducen el NameID y las declaraciones de atributos de la aserción SAML a los campos canónicos que usa el resto de AAM — nombre de usuario, correo electrónico, grupos, nombre para mostrar, atributos personalizados. El mismo mapeo alimenta el gating de MFA, las expresiones de acceso condicional, los logs de auditoría y las inyecciones de Backend SSO.
Una autenticación SAML no opera de forma aislada — se compone con el MFA en el borde (si el IdP no aplicó step-up), las expresiones de acceso condicional, la evaluación continua de confianza y la inyección de Backend SSO hacia el backend. La aserción SAML se convierte en una entrada de la sesión de AAM; no en toda la sesión.
SP SAML 2.0 conforme a estándares más las características operativas que hacen la federación segura y gestionable a escala.
El usuario llega a la aplicación, AAM lo redirige al IdP configurado con un AuthnRequest SAML firmado, el usuario inicia sesión en el IdP y el IdP devuelve la aserción firmada al endpoint Assertion Consumer Service de AAM. Se soportan ambos bindings: HTTP-Redirect para la solicitud saliente y HTTP-POST para la aserción entrante.
Para los despliegues donde el punto de partida del usuario es el IdP — una rampa de lanzamiento de portal en el IdP, un catálogo de aplicaciones, un portal de identidad del sector público — se acepta el SSO iniciado por IdP. El RelayState transporta el destino de aplicación previsto; así, el usuario aterriza en la página correcta después de consumir la aserción.
La firma de la aserción se valida contra el certificado de firma del IdP configurado; la audience coincide con el identificador del SP de AAM configurado; NotBefore y NotOnOrAfter determinan la ventana de validez; se aplica AudienceRestriction. Los ataques SAML conocidos (signature wrapping, signature stripping, deriva de NotBefore) se neutralizan explícitamente en lugar de tolerarse silenciosamente.
Cuando el IdP cifra la aserción (xmlenc), AAM descifra la aserción con la clave privada del SP configurada antes de la validación. Las aserciones cifradas son comunes para la federación de identidad del sector público y para los IdP que no quieren que el contenido de la aserción sea legible en la capa de binding. Las claves de cifrado se almacenan cifradas en el repositorio de configuración y nunca se registran en logs.
Cada IdP puede configurarse con un formato de NameID preferido (persistent, transient, email-address, unspecified) y un mapeo de los nombres de atributos SAML a los campos de sesión de AAM. Distintos IdP pueden presentar la identidad de formas distintas — un claim de identificador nacional, un correo electrónico, un identificador opaco único — y aun así producir el mismo formato de sesión canónico de AAM.
Un único gateway de AAM que se sitúa frente a muchos tenants puede enrutar cada tenant a su propio IdP. La selección se hace en el momento de la solicitud según el contexto de la aplicación o el tenant — sin un gateway separado por IdP, sin selector por usuario. El mismo gateway puede transportar una federación de identidad del sector público para un tenant y un IdP corporativo privado para otro de forma simultánea.
Cuando el IdP inicia un cierre de sesión, AAM acepta el LogoutRequest SAML, termina la sesión de AAM y señala a los backend que reciben inyección de Backend SSO. Cuando la aplicación inicia el cierre de sesión, AAM envía un LogoutRequest firmado hacia el IdP y espera el LogoutResponse antes de declarar que la sesión ha desaparecido. Se soporta el SLO front-channel.
El Single Logout back-channel basado en SOAP, el perfil SAML ECP (Enhanced Client/Proxy) para clientes sin navegador y la confirmación de sujeto holder-of-key para integraciones de alta seguridad están en la hoja de ruta. El objeto de configuración y el resto del pipeline del SP ya están preparados para ellos; lo que falta es el código específico del protocolo.
La mecánica que mantiene una federación SAML segura, actualizada y observable.
El metadata del IdP puede cargarse subiendo el XML de metadata proporcionado por el IdP, configurando una URL de metadata que AAM obtiene y cachea, o introduciendo manualmente los endpoints y certificados. La configuración manual es la opción realista para los IdP que no publican metadata conforme a estándares; donde funciona, se prefieren los otros dos métodos.
AAM publica su propio documento de metadata del SP en una URL estable; así, el operador del IdP puede importarlo a su almacén de confianza en lugar de transferir manualmente los endpoints y certificados. El metadata refleja la configuración en vivo del SP — URL de ACS actual, certificado de firma actual, endpoint de SLO actual.
Las claves de firma y los certificados del SP tienen una vida útil limitada. AAM soporta la rotación de claves con solapamiento — durante la ventana de rollover, tanto la clave antigua como la nueva se validan contra el metadata cacheado del IdP. Los operadores planifican la rotación con antelación; durante el periodo de solapamiento en tiempo de ejecución se aceptan ambas y la rotación entra en vigor de forma limpia.
Las aserciones llevan marcas de tiempo NotBefore y NotOnOrAfter. Los relojes reales se desvían; AAM aplica una ventana de tolerancia configurable; así, una pequeña desviación no rechaza aserciones válidas, mientras que las grandes desviaciones (indicador de configuración incorrecta o de replay) siguen siendo rechazadas. La tolerancia es por IdP; un IdP bien sincronizado recibe una ventana estrecha, un IdP problemático recibe un margen documentado.
Cada evento SAML — AuthnRequest saliente, aserción entrante, resultado de validación de firma, LogoutRequest de SLO, LogoutResponse — se registra con un ID de correlación que se vincula de vuelta a la sesión de AAM, a los backend(s) detrás de ella y a la identidad del usuario. La pregunta "quién inició sesión a través de qué IdP y cuándo" se responde con una sola consulta.
El refresco automático periódico del metadata del IdP desde la URL configurada, la detección de diferencias y la alerta al operador ante cambios de certificado de firma están en la hoja de ruta. La telemetría de rotación — métricas de antigüedad de clave, aviso de días hasta la fecha de caducidad, programación de rollover automático — también está planificada.
Aplicaciones que deben aceptar un IdP de federación de identidad nacional — típico para despliegues del sector público, sectores regulados y servicios SaaS contratados para compradores públicos. AAM termina la federación SAML en el borde y presenta una identidad limpia y verificada a la aplicación que tiene detrás.
IdP corporativos existentes que ya son autoritativos para la fuerza laboral. AAM se conecta como un SP SAML sin pedir al equipo del IdP que cambie nada. Las aplicaciones nuevas se unen a la federación no añadiendo una nueva librería SAML a cada base de código, sino añadiendo un registro en AAM.
Aplicaciones SaaS donde cada cliente trae su propio IdP. Un único gateway de AAM se sitúa frente a todos los tenants; el tráfico de cada tenant se enruta al IdP de ese tenant. Añadir un tenant no es un despliegue, sino añadir un registro de IdP al repositorio de configuración.
Algunos IdP autentican pero no aplican step-up MFA o acceso condicional — especialmente los gateways de federación antiguos. AAM acepta la autenticación del IdP, y luego monta su propio MFA, expresiones de acceso condicional y evaluación continua de confianza sobre ella antes de conceder acceso a la aplicación.
Conectemos AAM a su IdP — corporativo o de federación de identidad del sector público — y montemos el resto del motor de acceso con MFA, acceso condicional, confianza del dispositivo y Backend SSO sobre la aserción.