¿Qué es SAML (Security Assertion Markup Language)?

¿Qué es SAML?

SAML (Security Assertion Markup Language) es un estándar abierto basado en XML para intercambiar datos de autenticación y autorización entre un Identity Provider (IdP) y un Service Provider (SP). Estandarizado en 2005, SAML 2.0 es el protocolo SSO empresarial dominante — cuando una app SaaS dice "SSO soportado", casi siempre se refieren a SAML 2.0. Slack, Salesforce, AWS, Workday, Zoom y miles de otras aplicaciones empresariales todas soportan SAML.

El mecanismo central: cuando un usuario intenta loguearse en un Service Provider (tu app), el SP lo redirige al Identity Provider (Okta, Microsoft Entra ID, Google Workspace, Auth0). El IdP autentica al usuario (verifica contraseña, impone MFA), luego emite un documento XML firmado digitalmente llamado afirmación SAML. El navegador del usuario lleva esta afirmación de vuelta al SP, que verifica la firma contra la clave pública del IdP y confía en que el usuario es quien el IdP dice que es.

El flujo SAML (SP-initiated, el caso común)

1. El usuario accede al SP (ej. https://app.example.com) y clica "Iniciar sesión con SSO".
2. El SP redirige al IdP con un AuthnRequest SAML — un mensaje XML diciendo "por favor autentica este usuario por mí". La redirección pasa por el navegador del usuario vía binding HTTP-Redirect o HTTP-POST.
3. El IdP autentica al usuario. Username + contraseña, luego MFA, posiblemente políticas de acceso condicional. Si el usuario ya tiene una sesión IdP activa, este paso es invisible.
4. El IdP genera una Response SAML. Un documento XML que contiene una o más afirmaciones con claims sobre el usuario (nombre, email, pertenencias a grupos), firmado digitalmente con la clave privada del IdP.
5. El IdP redirige el navegador del usuario de vuelta a la URL ACS del SP (Assertion Consumer Service) con la Response firmada, típicamente como cuerpo HTTP POST codificado en base64.
6. El SP valida la Response. Comprueba la firma contra el certificado público publicado del IdP, valida timestamps (NotBefore/NotOnOrAfter), comprueba que la audience coincide con su entity ID esperado. Si todo cuadra, el SP crea una sesión local para el usuario.

El usuario típicamente experimenta esto como una sola redirección de navegador — clica "Iniciar sesión", ve brevemente la página IdP (o no) y aterriza de vuelta en la app ya autenticado. Tiempo total transcurrido: 1-3 segundos.

Qué hay en una afirmación SAML (el payload XML)

Una Response SAML 2.0 típica contiene:

• Issuer: Qué IdP firmó esto — usado para buscar la clave pública correcta.
• Signature: La firma digital XML sobre la Response (o la Assertion dentro).
• Subject: Identifica al usuario, típicamente como NameID (email, UUID o identificador transient/persistent).
• Conditions: Timestamps NotBefore y NotOnOrAfter que delimitan cuándo la afirmación es válida (normalmente una ventana de 5 minutos).
• AudienceRestriction: A qué SP está destinada esta afirmación. Si el entity ID del SP no coincide, rechaza.
• AuthnStatement: Cuándo y cómo se autenticó el usuario (contraseña, MFA, etc.).
• AttributeStatement: Atributos custom que el IdP incluye — email, nombre, apellido, pertenencias a grupos, departamento, manager, ID de empleado. El SP los usa para provisionar y autorizar al usuario.

Por qué SAML es verbose (y por qué persiste a pesar de eso)

SAML es famoso por ser complejo: namespaces XML, certificados X.509, múltiples opciones de firma/cifrado, decenas de campos opcionales. Comparado con JSON Web Tokens (JWT) usados en OpenID Connect, un mensaje SAML es 10-50× más grande en bytes.

¿Entonces por qué SAML aún domina el SSO empresarial?

• Efecto red. Cada IdP importante y cada SaaS empresarial ya soporta SAML. Los costes de cambio son enormes.
• Tooling maduro. 20 años de librerías, debuggers, IdPs de prueba. Los equipos de adquisiciones saben cómo evaluar el soporte SAML.
• Hábitos empresariales. Los compradores explícitamente requieren SAML en RFPs. "OIDC-only" es no-iniciador para la mayoría de adquisiciones grandes.
• Profundidad de seguridad genuina. SAML soporta casos de uso complejos (afirmaciones cifradas, cifrado de atributos, firma multi-tier) que protocolos más simples manejan torpemente.

Para integraciones nuevas entre sistemas modernos, OpenID Connect (construido sobre JWT y OAuth 2.0) es más simple y cada vez más preferido. Para SaaS empresarial, SAML aún se requiere — la mayoría de sistemas en producción soportan ambos.

Gotchas comunes de implementación SAML

• Clock skew. Las afirmaciones SAML tienen timestamps NotBefore y NotOnOrAfter. Si los relojes del IdP y SP difieren más de la tolerancia configurada (normalmente 60-300 segundos), la autenticación falla. Sincroniza todo por NTP.
• Rotación de certificados. Las firmas SAML usan certificados X.509 que expiran (típicamente 1-3 años). Fallar en rotar antes de la expiración tira el SSO a las 03:00 un martes. Recordatorios de calendario son obligatorios; el intercambio de metadatos (auto-rotación) es raro en la práctica.
• Mapeo de claims de grupo. El IdP envía grupos en la afirmación; el SP debe mapearlos a roles locales. Mapeos de grupo mal configurados son la fuente #1 de tickets "¿por qué no soy admin?".
• SP-initiated vs IdP-initiated. Algunas apps SaaS soportan ambos; algunas solo SP-initiated. IdP-initiated (el usuario empieza en el dashboard de Okta, clica el tile del SP) es conveniente pero introduce consideraciones de seguridad — el SP debe aceptar afirmaciones que no solicitó.
• Formato NameID. Diferentes IdPs por defecto a diferentes formatos NameID (email vs UUID persistente vs transient). El SP debe acordar cuál esperar o el matching se rompe.
• Protección de replay. El SP debe recordar IDs de afirmaciones recientemente validadas y rechazar duplicados. Sin esto, las afirmaciones interceptadas pueden ser replayed.

SAML vs OIDC vs OAuth 2.0

Los tres protocolos a menudo confundidos:

• SAML 2.0: Estándar de autenticación basado en XML. Dominante en SSO empresarial. Verbose pero robusto.
• OAuth 2.0: Framework de autorización — "¿puede esta app acceder a los datos de este usuario?" No establece identidad por sí solo.
• OpenID Connect (OIDC): Capa de autenticación construida sobre OAuth 2.0. Basado en JSON, tokens JWT. Moderno, más simple que SAML. Impulsa "Iniciar sesión con Google/Apple/Microsoft".

Guía práctica: implementa OIDC para signups self-service / consumer (más simple, amigable con JSON); añade SAML para clientes empresariales (obligatorio para muchos equipos de adquisiciones).

FAQ: SAML

¿Es SAML aún relevante en 2026?

Sí — para SSO empresarial, sigue siendo el estándar dominante. OIDC está ganando terreno para integraciones nuevas y autenticación consumer, pero la base instalada empresarial de SAML significa que será requerido en el futuro previsible. Planea soportar ambos.

¿Cuál es la diferencia entre SAML y OAuth?

Propósitos diferentes. SAML es authentication-first ("¿quién es este usuario?"). OAuth es authorization-first ("¿puede esta app acceder a los recursos de este usuario?"). A menudo se combinan — SAML para SSO, OAuth para acceso API. OIDC fusiona los dos añadiendo claims de identidad a OAuth.

¿Por qué SAML usa XML cuando JSON está en todas partes ahora?

Accidente histórico. SAML 2.0 se finalizó en 2005, antes de que JSON dominara la web. Para cuando JSON se volvió default, la base instalada empresarial de SAML era demasiado grande para migrar. Los protocolos nuevos (OIDC) usan JSON; SAML se queda en XML por compatibilidad.

¿Es SAML seguro?

Sí cuando se implementa correctamente. El protocolo está bien especificado y battle-tested. La mayoría de breaches SAML vienen de bugs de implementación (fallos de validación de firma, ataques de replay) en lugar de debilidades del protocolo. Usa una librería SAML battle-tested; no hagas el parsing XML a mano.

¿Cómo debuggeo una integración SAML?

Herramientas: extensión SAML-tracer de Firefox (captura y decodifica mensajes SAML), decodificadores SAML online (pega afirmaciones codificadas en base64, obtén XML legible), logs de debug del IdP (Okta, Auth0, Microsoft todos exponen trazas detalladas) y páginas de error del SP con modo verbose habilitado. La mayoría de roturas SAML son mismatch de firma o clock skew — comprueba esos primero.

¿Qué es SCIM y cómo se relaciona con SAML?

SCIM (System for Cross-domain Identity Management) automatiza el provisioning de usuarios entre IdP y SPs. SAML maneja la autenticación (login); SCIM maneja "crea este usuario cuando se añada al IdP, bórralo cuando se elimine". Juntos, SAML + SCIM es el estándar de oro para SaaS empresarial gestionado.

Cómo se relaciona LoadFocus con SAML SSO

LoadFocus soporta SAML 2.0 SSO en planes Enterprise (junto a OIDC). Para pruebas de carga de apps que usan auth SAML, nuestras pruebas de carga soportan flujos OAuth para tokens servicio-a-servicio — el patrón típico es usar una cuenta de servicio con intercambio de tokens en lugar de SAML basado en navegador para tráfico sintético. La monitorización de API valida que los endpoints protegidos por SAML responden correctamente cuando son disparados por automatización.