SAML - Lenguaje de marcado de aserción de seguridad
Lectura de 2 min aprox.
SAML (Security Assertion Markup Language) es un estándar abierto para intercambiar de forma segura información de autenticación y autorización basada en XML entre dominios diferentes. SAML 2.0 fue establecido por OASIS en 2005 y, durante más de 20 años, ha servido como el estándar de facto para el inicio de sesión único (SSO) en entornos empresariales. Aunque OpenID Connect (OIDC) está ganando protagonismo para las aplicaciones modernas, la demanda de SAML sigue siendo sólida por su compatibilidad con los sistemas empresariales existentes.
El flujo de autenticación de SAML 2.0
El flujo de autenticación de SAML tiene dos patrones: SP-initiated (originado desde el SP) e IdP-initiated (originado desde el IdP). En la práctica, SP-initiated se utiliza con mucha mayor frecuencia.
La estructura de una aserción SAML
Una aserción SAML es un documento XML mediante el cual el IdP transmite el resultado de la autenticación del usuario al SP. Se compone principalmente de tres elementos.
Describe cuándo y mediante qué método se autenticó al usuario. Incluye la hora de autenticación y el método de autenticación (contraseña, MFA, etc.).
Almacena la información de atributos del usuario (dirección de correo, departamento, rol, etc.). El SP usa esta información para realizar el control de acceso.
Describe si se permite el acceso a un recurso específico. Rara vez se usa en la práctica, y la autorización suele decidirse del lado del SP.
Comparación con OIDC
Tanto SAML como OIDC son protocolos que permiten la autenticación federada, pero difieren mucho en filosofía de diseño y base técnica. En proyectos nuevos, OIDC suele ser la primera opción, pero en entornos empresariales existentes no son pocos los casos en que SAML es obligatorio.
| Aspecto | SAML 2.0 | OIDC |
|---|---|---|
| Formato de datos | XML | JSON / JWT |
| Año de creación | 2005 | 2014 |
| Caso de uso principal | SSO empresarial | Aplicaciones web y móviles |
| Complejidad de implementación | Alta (firmas XML, gestión de certificados) | Baja (basada en JSON) |
| Soporte móvil | Difícil (asume redirecciones de navegador) | Soporte nativo |
| Tamaño del token | Grande (varios KB) | Pequeño (unos cientos de bytes) |
Por qué SAML persiste en los sistemas heredados
Aunque OIDC es más moderno y fácil de implementar, hay varias razones por las que SAML sigue siendo ampliamente utilizado en entornos empresariales. Primero, productos SaaS importantes como Salesforce, Workday y ServiceNow han admitido SAML durante años, y migrar las configuraciones de integración existentes a OIDC supone un alto costo. Segundo, los servicios internos de federación de Active Directory (AD FS) se construyeron asumiendo SAML, lo que dificulta la renovación de la infraestructura. Tercero, los requisitos de auditoría y cumplimiento a veces exigen un «protocolo probado». El artículo sobre la política de contraseñas corporativa también aborda la elección de un protocolo de SSO.
Una vulnerabilidad específica de SAML - ataques de envoltura de firma XML
Como SAML se basa en XML, presenta una vulnerabilidad única llamada envoltura de firma XML (XML Signature Wrapping, XSW). En este ataque, una aserción legítima ya firmada se mueve dentro del documento XML, y se inserta una aserción falsa creada por el atacante en una posición fuera del alcance de la verificación de firma. Si el analizador XML del SP examina nodos diferentes para la verificación de firma y para la referencia de valores, el atacante podría iniciar sesión como cualquier usuario. La clave de la defensa es implementar de forma estricta la lógica de verificación de la firma digital y prevenir la inyección de XPath.
- Durante la verificación de la firma, validar solo elementos específicos en lugar de todo el documento XML
- Mantener la biblioteca SAML en la última versión y aplicar los parches para las vulnerabilidades XSW conocidas
- Validar estrictamente el esquema de las aserciones recibidas del lado del SP
- Usar aserciones cifradas (EncryptedAssertion) siempre que sea posible
Conceptos erróneos comunes
Existe la idea errónea de que «SAML es antiguo, por lo que no es seguro», pero el diseño de seguridad del protocolo en sí es robusto. Los problemas surgen de fallos de implementación (verificación de firma laxa, rotación de certificados omitida, etc.), no de la especificación de SAML. Revisa los puntos de control de implementación al introducir SSO en la lista de verificación de seguridad para startups.libros sobre seguridad web (Amazon) también son una referencia útil.
Casos de uso reales
«En nuestra empresa usamos Microsoft Entra ID como IdP e integramos con más de 30 productos SaaS mediante SAML. Para los SaaS recién incorporados priorizamos el soporte de OIDC, pero nuestras integraciones con Salesforce y ServiceNow existentes siguen funcionando con SAML. La coexistencia de ambos protocolos es compleja, incluida la gestión de permisos de OAuth, pero una migración por fases es la opción realista.»
¿Te resultó útil este artículo?