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.

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.

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.

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.

La carga operativa mientras ambos protocolos coexisten

Una configuración en la que los servicios recién adoptados usan OIDC mientras los existentes siguen integrados mediante SAML aparece con frecuencia como estado transitorio hasta que la migración concluye. Lo que aumenta en ese periodo es menos la dificultad técnica que el trabajo de verificación: el IdP mantiene dos conjuntos de ajustes de integración para los mismos usuarios, de modo que añadir una cuenta, cambiar permisos o desactivar el acceso cuando alguien se marcha debe comprobarse en ambos. Los procedimientos de diagnóstico también se bifurcan: en el lado SAML hay que sospechar de la verificación de la firma y de la caducidad del certificado; en el lado OIDC, de la validación del token y del origen desde el que se obtienen las claves. La gestión de vencimientos tampoco puede unificarse, ya que certificados y credenciales de cliente se siguen en calendarios distintos. El lado OIDC es contiguo a la gestión de permisos de OAuth, por lo que conviene revisar a la vez el diseño de los ámbitos concedidos. La coexistencia en sí es difícil de evitar, pero si el inventario de qué servicio usa cada método no está actualizado, los cambios de permisos se omitirán en uno de los lados; por eso, fijar un plazo para la migración para que el estado transitorio no se vuelva permanente es el punto clave de la operación.