SAML y federación

SAML (Security Assertion Markup Language) es un estándar basado en XML para intercambiar datos de autenticación y autorización, predominante en el SSO empresarial.

• Permite que un proveedor corporativo de identidad responda por un usuario ante muchas aplicaciones.
• SAML 2.0 es anterior a OIDC y sigue estando profundamente implantado en la identidad B2B y de la fuerza laboral.

Comprender SAML es esencial para proteger la federación empresarial, donde un único fallo de confianza expone todas las aplicaciones conectadas.

La federación SAML tiene dos partes principales.

• El Proveedor de identidad (IdP) autentica al usuario y emite aserciones (Okta, Entra ID, Ping).
• El Proveedor de servicios (SP) es la aplicación que confía en el IdP y concede el acceso.

La confianza se establece fuera de banda mediante el intercambio de metadatos, incluidos los certificados de firma y las URL de los endpoints.

El artefacto central es la aserción, un documento XML que declara que el IdP autenticó a un sujeto.

• Subject identifica al usuario (NameID).
• Conditions define la ventana de validez y la audiencia prevista.
• AuthnStatement registra cómo y cuándo tuvo lugar la autenticación.
• AttributeStatement contiene roles, correo electrónico y claims de grupos.

El patrón más común es el SSO iniciado por el SP.

• El usuario accede al SP, que genera un AuthnRequest y redirige al IdP.
• El IdP autentica al usuario y envía mediante POST una Response firmada al servicio consumidor de aserciones (ACS) del SP.
• El SP valida la aserción y crea una sesión local.

La seguridad de SAML se basa en las firmas digitales XML. El IdP firma la aserción o la respuesta, o ambas, con su clave privada; el SP verifica la firma con el certificado de confianza.

• Firme la aserción en sí, no solo la respuesta externa.
• Verifique la firma con un certificado del IdP fijado a partir de los metadatos, no con uno incrustado en el mensaje.

La mayoría de los ataques contra SAML se dirigen a la lógica de validación de firmas.

XML Signature Wrapping es la clase de ataques contra firmas propia de SAML. El atacante conserva un elemento firmado válidamente, pero añade una segunda aserción falsificada que la lógica de la aplicación termina leyendo.

• La firma sigue verificándose correctamente contra el fragmento original.
• Sin embargo, la lógica de negocio procesa la aserción inyectada y sin firma.

Mitigación: utilice una biblioteca SAML reforzada, valide que el elemento firmado sea el que se consume y rechace los documentos con varias aserciones o aserciones ambiguas.

Una aserción debe estar vinculada al SP previsto. SAML proporciona restricciones explícitas.

• AudienceRestriction identifica el ID de entidad del SP para el que es válida la aserción.
• Recipient en SubjectConfirmation debe coincidir con la URL del ACS.

El SP debe hacer cumplir estas restricciones. Omitir la comprobación de audiencia permite reproducir en otra aplicación una aserción generada para una aplicación distinta.

Las aserciones son credenciales de corta duración y de un solo uso. Los SP deben imponerlo.

• Respete NotBefore y NotOnOrAfter con un margen de desfase de reloj reducido.
• Realice un seguimiento del ID de la aserción y rechace cualquier reutilización dentro de la ventana de validez.
• Exija TLS en el endpoint del ACS.

Sin seguimiento de la reutilización, una aserción capturada puede enviarse de nuevo antes de que caduque.

La federación permite escalar el SSO entre organizaciones, a veces mediante hubs o brokers que traducen entre protocolos.

• Cada enlace de confianza es un posible punto débil; un IdP comprometido suplanta a todos los usuarios.
• Los brokers de identidad pueden conectar SAML y OIDC, lo que requiere asignar cuidadosamente los claims.

Aplique el principio de mínimo privilegio al mapeo de atributos y supervise la aparición inesperada de nuevos registros de SP.

Modos de fallo recurrentes de SAML que conviene auditar:

• La firma no se verifica, o se firma la respuesta pero no la aserción.
• Vulnerabilidad frente a XML Signature Wrapping.
• Faltan comprobaciones de audiencia/destinatario.
• No hay protección contra repeticiones o las ventanas de validez son demasiado largas.
• Procesamiento de XML External Entity (XXE) en el SP.
• Se confía en el certificado incluido en el mensaje en lugar de utilizar metadatos fijados.

Ambos proporcionan SSO, pero su diseño es diferente.

• SAML: XML, enlaces POST/redirección del navegador, predominante en entornos empresariales y laborales, con herramientas maduras.
• OIDC: JSON/JWT, compatible con REST y más adecuado para aplicaciones móviles y SPA.

Muchas organizaciones utilizan ambos. El personal responsable de la seguridad debe conocer las reglas de validación de aserciones del protocolo que utilice cada aplicación, ya que la superficie de ataque es diferente.

Seleccione la mejor defensa para el ataque descrito.

Ideas clave:

• SAML es un sistema de SSO empresarial basado en XML entre un IdP y un SP, mediante aserciones firmadas.
• La seguridad depende de una correcta validación de firmas XML frente a un certificado fijado.
• Protéjase contra XML Signature Wrapping, las repeticiones y XXE.
• Imponga siempre restricciones de audiencia/destinatario y ventanas de validez.
• La federación amplía la confianza, pero multiplica el radio de impacto de un IdP comprometido.