SAML

SAML (Security Assertion Markup Language) es un estándar de inicio de sesión único (SSO) basado en XML publicado por OASIS en 2005. Se usa ampliamente en integraciones B2B empresariales — Okta, Ping Identity, Microsoft AD FS, Google Workspace, todo SaaS que vende a grandes empresas.

El modelo: un Proveedor de Identidad (IdP, por ejemplo Okta) autentica al usuario. El usuario llega a un Proveedor de Servicios (SP, por ejemplo Salesforce) con una aserción SAML firmada que prueba quiénes son. El SP verifica la firma contra la clave pública del IdP y confía en la afirmación.

SAML vs OAuth2/OIDC: SAML es más antiguo, basado en XML, diseñado para SSO empresarial. OAuth/OIDC están basados en JSON, diseñados originalmente para autorización delegada (“permitir que esta aplicación lea mi Gmail”) y posteriormente extendidos a la autenticación (OIDC). Las nuevas integraciones empresariales usan cada vez más OIDC; el SaaS empresarial existente a menudo todavía requiere SAML porque los IdPs de los clientes lo requieren.

La especificación de firma XML que usa SAML es notoriamente propensa a errores — existen ataques de envoltura de firma XML en muchas implementaciones. Las bibliotecas modernas (por ejemplo, python-saml, las de OneLogin) manejan esto correctamente de forma predeterminada; implementar el tuyo propio es mala idea.

Bindings de SAML — cómo viaja la aserción: SAML define varios bindings de transporte. HTTP Redirect comprime y codifica en base64 la solicitud en una cadena de consulta URL (limitada por la longitud de URL del navegador); HTTP POST envía un blob codificado en base64 en un formulario enviado automáticamente mediante JavaScript (el más común en 2026); HTTP Artifact pasa un token de referencia corto que el SP intercambia fuera de banda por la aserción completa. POST es el predeterminado moderno porque maneja tamaños de aserción que superan con comodidad los límites de URL y evita filtrar la aserción en registros de proxy. La aserción en sí se envuelve en base64 y se firma con SHA-256.

Problemas operativos en implementaciones SAML empresariales: desviación de reloj entre IdP y SP (las aserciones tienen una ventana de validez de 5 minutos por defecto — una hora de servidor mal configurada rompe el inicio de sesión para todos), rotación de certificados (el certificado de firma del IdP expira cada 1-3 años y debe rotarse antes de esa fecha o todo SSO falla simultáneamente), y desajustes de formato NameID (el IdP emite emailAddress pero el SP espera IDs opacos persistent). La historia de guerra empresarial clásica es una interrupción de SSO un lunes por la mañana porque el certificado del IdP expiró silenciosamente el domingo por la noche y nadie se encargaba de la renovación. Referencia: Especificación central de SAML 2.0 de OASIS.

Ejemplo práctico

Un empleado hace clic en “Iniciar sesión con SSO de empresa” en app.example.com. El SP (Proveedor de Servicios) genera un documento XML <AuthnRequest> de SAML y lo envía por POST al IdP en sso.acme.com/saml. El IdP autentica al usuario (probablemente mediante contraseña + WebAuthn) y devuelve una <Response> de SAML que contiene una <Assertion> con: el correo electrónico del usuario (NameID), membresías de grupo (AttributeStatement), ventana de validez (NotBefore / NotOnOrAfter ~5 minutos), y restricción de audiencia (debe ser exactamente app.example.com). El XML está firmado con la clave RSA-2048 del IdP usando SHA-256. El navegador envía automáticamente por POST este blob codificado en base64 de vuelta a app.example.com/saml/acs. El SP verifica la firma contra el certificado público precompartido del IdP, verifica la ventana de validez y la audiencia, extrae el correo electrónico y crea una sesión local. Todo el intercambio son dos redirecciones HTTP y es invisible para el usuario más allá de la pantalla de inicio de sesión del IdP.

Cuándo y por qué importa

Si vendes SaaS B2B, el soporte de SAML es la característica habilitante para ventas empresariales — la mayoría de las empresas con más de 500 empleados exigen que todo acceso a SaaS pase por su IdP para el control de desincorporación (cuando un empleado se va, el IdP revoca su sesión y pierde acceso a todos los SaaS conectados de inmediato). Los incidentes de seguridad modernos en proveedores de SaaS (Okta 2022, Cloudflare 2023) se rastrean hasta la capa de SAML o token de sesión en lugar de contraseñas específicamente porque SSO es la credencial de registro. La lista de verificación defensiva para cualquier implementación de SAML: validar la firma en cada aserción (no solo el envoltorio de respuesta), validar InResponseTo para prevenir repetición, validar audiencia y destinatario, aplicar estrictamente la ventana de tiempo, y almacenar la huella digital del certificado del IdP fuera de banda para que una URL de metadatos comprometida no pueda intercambiar silenciosamente la clave de confianza. Referencia: OWASP SAML Security Cheat Sheet.