SAML 2.0: el estándar de federación empresarial que OIDC no ha podido jubilar
SAML 2.0 consolidó la federación de identidad en el mundo empresarial con un modelo basado en XML, aserciones firmadas y metadatos intercambiados entre organizaciones. Dos décadas después, sigue siendo el protocolo dominante en B2B y SSO corporativo a pesar de la presión de OIDC, precisamente porque resolvió problemas que JSON y REST todavía no resuelven con la misma claridad.
Cada pocos años alguien anuncia la muerte inminente de SAML y, sin embargo, los portales B2B, las integraciones con Salesforce, ServiceNow, Workday y media nómina de herramientas corporativas siguen hablando SAML 2.0 como lengua materna. OIDC ha conquistado el terreno del consumidor y de la API, pero en el territorio donde un acuerdo de federación se firma entre departamentos legales antes que entre ingenieros, SAML sigue siendo el estándar. Este artículo forma parte de la serie La evolución de la seguridad en aplicaciones modernas.
Por qué SAML existe y por qué sobrevive
SAML 2.0 se ratificó por OASIS en marzo de 2005 como consolidación de tres líneas que avanzaban en paralelo. SAML 1.0 y 1.1 habían establecido el formato de aserciones, Shibboleth (Internet2) había aportado la experiencia de federación académica, y Liberty Alliance había definido perfiles de identidad para empresa. SAML 2.0 unificó los tres linajes en un único estándar.
El contexto en el que nació explica muchas de sus decisiones. A mediados de los 2000 la arquitectura empresarial estaba dominada por SOAP, WS-Security y un ecosistema maduro de firma XML. No existía JSON en el vocabulario empresarial, y REST estaba emergiendo. SAML se construyó con las herramientas del momento: firma XML robusta, cifrado, extensibilidad por espacios de nombres y formalidad contractual en los metadatos.
Esa herencia es hoy tanto su debilidad percibida como su fortaleza real. La verbosidad XML y la complejidad de XML-DSig resultan incómodas frente a un ID Token compacto. A cambio, SAML ofrece un marco donde dos organizaciones pueden federar identidad con responsabilidades auditables, políticas de cifrado claras y un modelo de confianza explícito en metadatos firmados. Jubilar ese ecosistema requiere más que un protocolo mejor.
Los actores del protocolo
SAML define dos roles fundamentales y un conjunto preciso de artefactos que viajan entre ellos. El IdP (Identity Provider) es la autoridad que autentica al usuario y emite aserciones sobre su identidad. Típicamente vive dentro de la organización del usuario: ADFS, Azure AD, Okta, Keycloak, Shibboleth. El SP (Service Provider) es la aplicación que consume esas aserciones y concede acceso en base a ellas. En un escenario B2B es la aplicación externa a la que los empleados acceden: Salesforce, Workday, una herramienta de analítica, un portal de proveedores.
La relación entre IdP y SP se establece mediante un intercambio de metadatos previo. Ambos publican un documento XML con sus identificadores (entityID), sus endpoints (dónde recibir respuestas, dónde resolver artefactos), sus certificados de firma y cifrado, los bindings soportados y los formatos de NameID que aceptan. Este intercambio es el acuerdo técnico de federación. Cambiarlo implica típicamente un ticket, un certificado rotado y una ventana de mantenimiento coordinada.
Aserciones: el vehículo de la identidad
El artefacto central de SAML es la aserción. Es un documento XML firmado por el IdP que contiene tres tipos de declaraciones. La AuthnStatement afirma que el usuario se autenticó en un momento concreto con un método concreto (el contexto de autenticación, AuthnContextClassRef: contraseña, certificado, MFA, kerberos, etc.). La AttributeStatement transporta atributos del usuario: correo electrónico, grupos, departamento, roles, cualquier cosa que el IdP y el SP hayan acordado mapear. La AuthzDecisionStatement (raramente usada) transporta decisiones de autorización para un recurso concreto; su caso de uso cayó en desuso frente a motores dedicados.
Cada aserción viaja dentro de un mensaje SAML más amplio, normalmente una Response que responde a un AuthnRequest previo del SP. La aserción lleva un Subject con un NameID, un intervalo de validez (Conditions con NotBefore y NotOnOrAfter), una audiencia restringida (AudienceRestriction que vincula la aserción al SP concreto) y las declaraciones correspondientes. Todo firmado, opcionalmente cifrado en el elemento EncryptedAssertion para que solo el SP destinatario pueda leerlo.
NameID y los formatos de identificación
El NameID es cómo el IdP identifica al usuario frente al SP. SAML estandariza varios formatos, y la elección no es trivial. Persistent produce un identificador opaco y estable por pareja IdP-SP: el mismo usuario aparece siempre con el mismo ID ante un SP concreto, pero con un ID distinto ante otro SP. Es la opción correcta para privacidad, porque impide la correlación entre SPs. Transient produce un identificador efímero distinto en cada sesión, usado cuando la federación no necesita persistir estado del usuario. Email usa la dirección de correo como identificador y es el más común en federación empresarial, a costa de exponer una identidad correlacionable. Existen también formatos kerberos, X.509 y otros menos frecuentes.
La decisión del formato tiene implicaciones legales y operativas: cambiar de email a persistent para una integración ya desplegada rompe todas las cuentas vinculadas en el SP. Es de esas decisiones que se toman al principio y rara vez se revisan.
Bindings: cómo viajan los mensajes
SAML separa contenido y transporte con los bindings. HTTP Redirect codifica el mensaje comprimido en la query string: bien para peticiones pequeñas del SP al IdP, mal para respuestas grandes con aserciones firmadas. HTTP POST envía el mensaje como campo de formulario en un POST automático y es el binding universal para respuestas del IdP al SP. SOAP permite intercambio back-channel directo entre servidores, usado en Single Logout y en el perfil ECP. Artifact emite un handle corto que el SP resuelve por back-channel contra el IdP, minimizando el tamaño visible al navegador a costa de exigir conectividad directa.
SP-initiated e IdP-initiated
En SP-initiated el usuario llega al SP, que genera un AuthnRequest y redirige al IdP. Tras autenticar, el IdP devuelve una Response con la aserción. Es el flujo limpio y recomendado.
En IdP-initiated el usuario parte del portal del IdP y este envía una aserción no solicitada al SP. Es cómodo para portales corporativos pero rompe el vínculo entre petición y respuesta, lo que complica la defensa frente a aserciones inyectadas o reutilizadas. Las guías modernas lo desaconsejan salvo con controles adicionales explícitos.
Firma XML y sus trampas
La seguridad criptográfica de SAML descansa en XML-DSig. La aserción se firma (y a veces el mensaje completo) referenciando elementos por ID y produciendo un SignatureValue calculado sobre la canonicalización de los nodos referenciados. La validación implica recorrer referencias, canonicalizar, recomputar y comparar.
Esta flexibilidad ha sido fuente histórica de vulnerabilidades. El ataque de XML Signature Wrapping (XSW), documentado en múltiples variantes desde 2005, explota la separación entre el nodo firmado y el nodo efectivamente leído por la aplicación. Un atacante inserta una aserción maliciosa en un punto del documento que la lógica del SP lee como si fuera la firmada, mientras la firma original sigue validando sobre otro nodo todavía presente. La defensa exige validar que el nodo firmado es exactamente el nodo procesado, con rutas explícitas y comprobaciones estrictas. Librerías maduras lo hacen; implementaciones artesanales han fallado repetidamente.
El otro patrón clásico es la confusión de algoritmos de firma. Algunas implementaciones aceptaban el algoritmo declarado dentro del propio documento firmado sin contrastarlo con una lista blanca configurada, abriendo la puerta a degradar a algoritmos débiles o incluso a none en versiones antiguas. El principio general se repite: el algoritmo de validación lo decide el SP, no el atacante.
Cualquier integración SAML que no valide explícitamente que el nodo firmado es exactamente el nodo utilizado, con ruta XPath verificada, está expuesta a XSW. La antigüedad del vector no lo hace irrelevante: sigue apareciendo en auditorías.
Metadata, certificados y Single Logout
Los metadatos son el contrato técnico entre IdP y SP, y contienen los certificados con los que cada parte firma. La rotación es el punto donde muchas federaciones se rompen: un certificado caduca un domingo por la noche, el IdP emite con la clave nueva, el SP sigue con la vieja configurada a mano y los usuarios no pueden entrar. La práctica recomendada es consumir metadatos automáticamente desde una URL bien conocida, respetar periodos de solapamiento y automatizar la recarga.
SLO (Single Logout) pretende que cerrar sesión en un SP o en el IdP termine las sesiones en todos los SPs conectados. La teoría es limpia; la práctica es frágil. Propagar mensajes a cada SP, manejar fallos parciales y depender de cookies de terceros que los navegadores bloquean hace que muchas implementaciones opten por cerrar solo la sesión local y dejar expirar las demás.
SAML frente a OIDC
En capacidad, ambos hacen cosas parecidas: autenticar un usuario y comunicar esa autenticación a una aplicación externa. Una aserción SAML y un ID Token OIDC transportan información similar. La diferencia está en el formato (XML firmado frente a JWT), el transporte (formularios POST frente a redirecciones) y el modelo de confianza (metadatos XML firmados frente a documentos de descubrimiento y JWKS).
Filosóficamente, SAML pertenece a la era de SOAP y los acuerdos bilaterales. OIDC pertenece a la era JSON/REST con descubrimiento automático. Esa diferencia cultural explica por qué SAML persiste en universidades, banca, gobierno y SaaS B2B empresarial, y OIDC domina en móvil, APIs y SSO de consumo. El IdP corporativo (Keycloak, Okta y los IdP modernos) expone los dos protocolos a la vez, SAML para el catálogo SaaS empresarial y OIDC para aplicaciones internas modernas. La pregunta interesante no es “SAML u OIDC” sino “cuándo cada uno”.
Para un SP B2B que vende a empresas Fortune 500, soportar SAML no es una opción de roadmap, es una casilla en el RFP. Para una API REST nueva dirigida a desarrolladores, ofrecer SAML como única opción es un mensaje de que el producto no entiende su mercado.
Cuándo elegir SAML
SAML es la elección correcta cuando la integración es B2B empresarial y la contraparte espera SAML, cuando el SP se integra en un catálogo corporativo (Okta, Azure AD, OneLogin) que ya gestiona SAML como primer lenguaje, cuando hay requisitos regulatorios que cita explícitamente SAML o WS-Federation, y cuando la federación académica vía eduGAIN o análogos es un caso de uso. Es también la respuesta pragmática para extender SSO a aplicaciones legadas que lo soportaban desde 2008 y no van a migrarse.
No tiene sentido elegirlo para APIs REST modernas, para aplicaciones móviles nativas, para integraciones con servicios de consumo (Google, GitHub, Apple) ni para escenarios donde el cliente es principalmente un script, una CLI o un servicio automatizado. En esos terrenos OIDC y OAuth 2.0 son simplemente mejores herramientas.
Cómo encaja con el resto de la arquitectura
SAML es la capa de federación que alimenta de identidad verificada al resto del sistema, igual que lo hace OIDC. Tras una autenticación exitosa, la autorización se delega a los mismos motores de política que cualquier arquitectura moderna usaría. La identidad federada por SAML puede traducirse a un JWT interno para viajar hacia servicios downstream y convivir con flujos mTLS o SPIFFE en la capa máquina a máquina. En entornos Zero Trust, SAML resuelve la autenticación del usuario humano mientras el resto del andamiaje verifica cada solicitud subsiguiente.
Artículos relacionados en esta serie
Referencias
- OASIS (marzo 2005). Security Assertion Markup Language (SAML) V2.0.
- OASIS. SAML V2.0 Core, Bindings, Profiles y Metadata Specifications.
- W3C. XML Signature Syntax and Processing.
- Somorovsky, J. et al. (2012). On Breaking SAML: Be Whoever You Want to Be. USENIX Security.
- OASIS. SAML V2.0 Errata y Security and Privacy Considerations.
- NIST SP 800-63C (2017). Digital Identity Guidelines: Federation and Assertions.