El problema fundamental que SAML intentó resolver fue la necesidad de un mecanismo estandarizado para la autenticación y autorización entre múltiples servicios web, permitiendo a los usuarios acceder a diversas aplicaciones con una única credencial (Single Sign-On). Surgió en un momento de transición de la Web 1.0 a la Web 2.0, donde la proliferación de servicios en línea, especialmente en entornos académicos y corporativos, demandaba una solución de identidad federada. Su creación en 2002 por OASIS, a partir de la consolidación de múltiples propuestas, refleja la urgencia de esta necesidad en una era donde los protocolos de seguridad web aún estaban en sus primeras etapas.
Sin embargo, la tesis central de este análisis es que, a pesar de su éxito inicial en establecer la base de la industria SSO, SAML es un ejemplo de 'diseño fractalmente deficiente'. Su dependencia de XML, un formato inherentemente complejo, y un enfoque de diseño 'kitchen-sink' (intentando abarcar demasiados casos de uso de antemano) han llevado a una acumulación de vulnerabilidades de seguridad, dificultades de implementación y una falta de adaptabilidad a las arquitecturas web modernas. La complejidad de la validación de firmas XML, en particular, ha sido una fuente persistente de fallos de seguridad, haciendo que el protocolo sea insostenible a largo plazo frente a alternativas más ágiles y seguras.
Arquitectura del Sistema
La arquitectura de SAML se basa en el intercambio de aserciones de seguridad (assertions) entre tres roles principales: el Principal (el usuario), el Identity Provider (IdP) y el Service Provider (SP). El IdP es responsable de autenticar al Principal y emitir aserciones SAML, mientras que el SP consume estas aserciones para otorgar acceso al Principal a un recurso protegido. Las aserciones son documentos XML firmados digitalmente que contienen información sobre la identidad del usuario y sus atributos.
El flujo de autenticación SAML más común, el 'Web Browser SSO Profile', implica redirecciones HTTP entre el navegador del usuario, el IdP y el SP. El IdP genera una respuesta SAML (SAMLResponse) que contiene la aserción firmada, la cual es enviada al SP a través del navegador del usuario (típicamente mediante un POST HTTP). El SP debe validar esta aserción, lo que implica una compleja validación de la firma XML (XML Signature Validation) y la canonicalización del XML (C14N) para asegurar que la representación de los datos sea consistente. Esta validación es la piedra angular de la seguridad de SAML, pero también su mayor debilidad debido a la complejidad inherente de XML y sus múltiples formas de representación. SAML también define varios 'bindings' (HTTP Redirect, HTTP POST, SOAP, Artifact) para el transporte de mensajes, lo que añade otra capa de complejidad y posibles vectores de ataque. La especificación es vasta y muchas de sus características, como el 'artifact binding' o el uso de SOAP, han caído en desuso, pero su presencia contribuye a la sobrecarga de diseño.
Flujo de Autenticación SAML (Web Browser SSO Profile)
- 1 Usuario Intenta acceder a un recurso protegido en el SP.
- 2 SP Detecta que el usuario no está autenticado y redirige al IdP.
- 3 IdP Autentica al usuario (si no lo ha hecho ya).
- 4 IdP Genera una SAMLResponse firmada con la aserción de seguridad.
- 5 IdP Envía la SAMLResponse al navegador del usuario (HTTP POST).
- 6 Usuario El navegador envía la SAMLResponse al SP.
- 7 SP Valida la firma XML y la aserción. Otorga acceso al recurso.
| Capa | Tecnología | Justificación |
|---|---|---|
| security | SAML (Security Assertion Markup Language) | Protocolo de autenticación y autorización federada para Single Sign-On. vs OpenID Connect (OIDC), OAuth 2.0, Kerberos |
| data-processing | XML (Extensible Markup Language) | Formato de datos subyacente para las aserciones y mensajes SAML. vs JSON, YAML, Protocol Buffers |
| security | XML Signature (XML-DSig) | Mecanismo para firmar digitalmente las aserciones SAML y asegurar su integridad y autenticidad. vs JSON Web Signature (JWS) |
| security | Canonical XML (C14N) | Algoritmo para producir una representación consistente de un documento XML antes de la firma, crucial para la validación de firmas. vs Algoritmos de canonicalización específicos de otros formatos |
Trade-offs
Ganancias
- ▲ Interoperabilidad inicial en SSO
- △ Flexibilidad de transporte (no solo HTTP)
Costes
- ▲ Complejidad de implementación y mantenimiento
- ▲ Vulnerabilidad a ataques de firma XML (XSW)
- ▲ Falta de adaptabilidad a arquitecturas modernas (móvil, SPA, IoT)
- ▲ Sobrecarga de características no utilizadas ('kitchen-sink')
Fundamentos Teóricos
El problema de la autenticación distribuida y la confianza federada ha sido un tema recurrente en la investigación en seguridad informática y sistemas distribuidos. La necesidad de un mecanismo robusto para verificar la identidad a través de fronteras administrativas se remonta a los primeros días de la computación en red. Conceptos como los 'trusted third parties' y los 'certificates' son fundamentales, predichos por trabajos como 'A Method for Obtaining Digital Signatures and Public-Key Cryptosystems' de Rivest, Shamir y Adleman (1978), que sentó las bases de la criptografía de clave pública esencial para las firmas digitales en SAML.
La complejidad de la validación de firmas XML y los ataques de 'XML signature wrapping' (XSW) se relacionan con el problema más general de la 'parser differential vulnerability'. Este tipo de vulnerabilidad ocurre cuando diferentes parsers de un mismo formato de datos interpretan la misma entrada de manera inconsistente, lo que puede ser explotado para eludir controles de seguridad. Este fenómeno no es exclusivo de XML; se ha observado en otros formatos y protocolos, y es un recordatorio de que la robustez de un protocolo depende críticamente de la implementación consistente de sus especificaciones, especialmente en el manejo de la canonicalización y la firma de datos. La investigación sobre XSW, como 'On Breaking SAML: Be Whoever You Want to Be' (2012), expuso cómo la complejidad de XML y su canonicalización pueden ser explotadas, conectando la teoría de la seguridad con las deficiencias prácticas de SAML.