SAML arrastra un diseño roto y ya toca jubilarlo en favor de OIDC
Trail of Bits sostiene que el protocolo de autenticación está aplastado por su propia complejidad y que la validación de firmas XML lo hace irrecuperable. Propone OpenID Connect como reemplazo.
SAML cumple más de dos décadas en producción y hay quien pide formalmente su retirada. Un análisis de la firma de seguridad Trail of Bits sostiene que el protocolo está aplastado por su propia complejidad y que la pieza sobre la que se apoya, la validación de firmas XML, es tan frágil que ninguna implementación puede considerarse a salvo. La propuesta es deprecarlo y migrar a OpenID Connect (OIDC).
Un protocolo hecho a base de comité
El Security Assertion Markup Language nació en 2002 dentro del comité de servicios de seguridad de OASIS, y su origen se nota. A la especificación se fusionaron cuatro protocolos XML anteriores: S2ML de Netegrity, AuthXML de Securant, X-TASS de VeriSign e ITML de Jamcracker. Un comité de subcomités con reuniones periódicas da como resultado un diseño de cocina, donde cada parte mete lo suyo y nadie poda.
El empujón inicial vino de la universidad, no de la empresa. CAS apareció en Yale en 2002, Shibboleth en Internet2 en 2003, ADFS en Microsoft ese mismo año y simpleSAMLphp hacia 2007 en Uninett. Cuando el SaaS empezó a multiplicar los servicios web a los que había que autenticarse, esa base ya estaba puesta y la industria de identidad la aprovechó: Ping Identity (2002), OneLogin (2009), Okta (2009) y Duo Security (2010) se construyeron en buena medida sobre SAML.
El talón de Aquiles sigue abierto
Aquí está el problema que el texto subraya. Los ataques de signature wrapping (XSW) son la flecha en el talón del protocolo. El trabajo de referencia es "On Breaking SAML: Be Whoever You Want to Be", de 2012, que llevó la teoría a la práctica y produjo una forma automatizada de comprobar si una implementación era vulnerable. Catorce años después, XSW sigue presente en productos desplegados.
Y antes de llegar a la lógica propia de SAML, cualquier librería tiene que lidiar con la herencia de XML: XXE, expansión de entidades (el clásico "billion laughs"), recuperación de DTD con SSRF de regalo, e inyección en XPath, XQuery, XInclude, XSLT y CDATA. En XML hay etiquetas, elementos, atributos, comentarios, espacios de nombres, esquemas, CDATA y DOCTYPE; en JSON hay claves, valores, objetos y listas. Esa diferencia de superficie es superficie de ataque.
Thomas Ptacek lo resumió en 2023: la mayoría de implementaciones en producción acaban envolviendo libxmlsec, "una base de código C enrevesada que nadie lee". El artículo pone un contraejemplo: simpleSAMLphp resistió XSW cuando casi nadie sabía qué era eso.
Qué implica para quien lo opera
SAML no se va a apagar mañana. Está embebido en proveedores de identidad, en pasarelas on-premise y en integraciones corporativas que nadie toca porque funcionan. Pero la decisión de arquitectura ya no es neutra: si estás montando un flujo de autenticación nuevo, el coste de auditar la parte XML recae en ti, y el ecosistema de herramientas y análisis se ha movido hacia OIDC. El análisis no da plazos ni un plan de migración, y esa es la parte que falta: deprecar un protocolo que sostiene el SSO de media empresa no es cuestión de publicar un aviso.
