El lenguaje de marcado de aserción de seguridad ( SAML , pronunciado SAM-el , / ˈ s æ m əl / ) [1] es un estándar abierto para intercambiar datos de autenticación y autorización entre partes, en particular, entre un proveedor de identidad y un proveedor de servicios . SAML es un lenguaje de marcado basado en XML para afirmaciones de seguridad (declaraciones que utilizan los proveedores de servicios para tomar decisiones de control de acceso). SAML también es:
Un caso de uso importante que aborda SAML es el inicio de sesión único (SSO) en el navegador web . El inicio de sesión único es relativamente fácil de lograr dentro de un dominio de seguridad (usando cookies , por ejemplo), pero extender el SSO a través de dominios de seguridad es más difícil y resultó en la proliferación de tecnologías propietarias no interoperables. El perfil SSO del navegador web SAML se especificó y estandarizó para promover la interoperabilidad. [2]
La especificación SAML define tres roles: el principal (normalmente un usuario humano), el proveedor de identidad (IdP) y el proveedor de servicios (SP). En el caso de uso principal abordado por SAML, el principal solicita un servicio al proveedor de servicios. El proveedor de servicios solicita y obtiene una afirmación de autenticación del proveedor de identidad. Sobre la base de esta afirmación, el proveedor de servicios puede tomar una decisión de control de acceso , es decir, puede decidir si realiza el servicio para el principal conectado.
En el centro de la aserción SAML hay un sujeto (un principal dentro del contexto de un dominio de seguridad particular) sobre el cual se afirma algo. El sujeto suele ser (pero no necesariamente) un ser humano. Al igual que en la descripción técnica de SAML 2.0, [3] los términos sujeto y principal se utilizan indistintamente en este documento.
Antes de entregar la aserción basada en el sujeto del IdP al SP, el IdP puede solicitar cierta información al principal (como un nombre de usuario y contraseña) para autenticar al principal. SAML especifica el contenido de la aserción que se pasa del IdP al SP. En SAML, un proveedor de identidad puede proporcionar afirmaciones SAML a muchos proveedores de servicios. De manera similar, un SP puede confiar en las afirmaciones de muchos IdP independientes. [ cita necesaria ]
SAML no especifica el método de autenticación en el proveedor de identidad. El IdP puede utilizar un nombre de usuario y una contraseña, o alguna otra forma de autenticación, incluida la autenticación multifactor . Un servicio de directorio como RADIUS , LDAP o Active Directory que permite a los usuarios iniciar sesión con un nombre de usuario y contraseña es una fuente típica de tokens de autenticación en un proveedor de identidad. [4] Los populares servicios de redes sociales de Internet también proporcionan servicios de identidad que, en teoría, podrían utilizarse para respaldar los intercambios SAML.
El Comité Técnico de Servicios de Seguridad (SSTC) de la Organización para el Avance de los Estándares de Información Estructurada (OASIS) , que se reunió por primera vez en enero de 2001, fue autorizado "para definir un marco XML para el intercambio de información de autenticación y autorización". [5] Con este fin, durante los dos primeros meses de ese año se aportó a la SSTC la siguiente propiedad intelectual:
Sobre la base de estas contribuciones iniciales, en noviembre de 2002 OASIS anunció la especificación Security Assertion Markup Language (SAML) 1.0 como estándar de OASIS. [6]
Mientras tanto, Liberty Alliance , un gran consorcio de empresas, organizaciones gubernamentales y sin fines de lucro, propuso una extensión del estándar SAML llamada Liberty Identity Federation Framework (ID-FF). [7] Al igual que su predecesor SAML, Liberty ID-FF propuso un marco de inicio de sesión único, estandarizado, multidominio, basado en web. Además, Liberty describió un círculo de confianza en el que se confía en que cada dominio participante documente con precisión los procesos utilizados para identificar a un usuario, el tipo de sistema de autenticación utilizado y cualquier política asociada con las credenciales de autenticación resultantes. Otros miembros del círculo de confianza podrían luego examinar estas políticas para determinar si deben confiar en dicha información. [8]
Mientras Liberty desarrollaba ID-FF, SSTC comenzó a trabajar en una actualización menor del estándar SAML. La especificación SAML 1.1 resultante fue ratificada por el SSTC en septiembre de 2003. Luego, en noviembre de ese mismo año, Liberty contribuyó con ID-FF 1.2 a OASIS, sembrando así las semillas para la próxima versión principal de SAML. En marzo de 2005, se anunció SAML 2.0 como estándar OASIS. SAML 2.0 representa la convergencia de Liberty ID-FF y las extensiones propietarias aportadas por el proyecto Shibboleth , así como las primeras versiones del propio SAML. La mayoría de las implementaciones de SAML admiten la versión 2.0, mientras que muchas aún admiten la versión 1.1 para lograr compatibilidad con versiones anteriores. En enero de 2008, las implementaciones de SAML 2.0 se volvieron comunes en el gobierno, la educación superior y las empresas comerciales de todo el mundo. [8]
SAML ha pasado por una revisión menor y una revisión mayor desde la versión 1.0.
Liberty Alliance contribuyó con su Marco de Federación de Identidad (ID-FF) al OASIS SSTC en septiembre de 2003:
Las versiones 1.0 y 1.1 de SAML son similares aunque existen pequeñas diferencias. [9] Sin embargo, las diferencias entre SAML 2.0 y SAML 1.1 son sustanciales. Aunque los dos estándares abordan el mismo caso de uso, SAML 2.0 es incompatible con su predecesor.
Aunque ID-FF 1.2 se contribuyó a OASIS como base de SAML 2.0, existen algunas diferencias importantes entre SAML 2.0 e ID-FF 1.2. En particular, las dos especificaciones, a pesar de tener raíces comunes, son incompatibles. [8]
SAML se basa en una serie de estándares existentes:
SAML define aserciones, protocolos, enlaces y perfiles basados en XML. El término SAML Core se refiere a la sintaxis y semántica general de las aserciones SAML, así como al protocolo utilizado para solicitar y transmitir esas aserciones de una entidad del sistema a otra. El protocolo SAML se refiere a lo que se transmite, no a cómo (esto último está determinado por la elección del enlace). Por lo tanto, SAML Core define aserciones SAML "simples" junto con elementos de solicitud y respuesta SAML.
Un enlace SAML determina cómo las solicitudes y respuestas SAML se asignan a protocolos de comunicación o mensajería estándar. Un enlace importante (síncrono) es el enlace SAML SOAP.
Un perfil SAML es una manifestación concreta de un caso de uso definido que utiliza una combinación particular de aserciones, protocolos y enlaces.
Una aserción SAML contiene un paquete de información de seguridad:
<saml:Aseveración...> .. </saml:Aserción>
En términos generales, una parte que confía interpreta una afirmación de la siguiente manera:
La afirmación A fue emitida en el momento t por el emisor R con respecto al sujeto S, siempre que las condiciones C sean válidas.
Las afirmaciones SAML normalmente se transfieren de los proveedores de identidad a los proveedores de servicios. Las aserciones contienen declaraciones que los proveedores de servicios utilizan para tomar decisiones de control de acceso. SAML proporciona tres tipos de declaraciones:
Las declaraciones de autenticación afirman al proveedor de servicios que el principal efectivamente se autenticó con el proveedor de identidad en un momento determinado utilizando un método de autenticación particular. Se puede revelar otra información sobre el principal autenticado (llamado contexto de autenticación ) en una declaración de autenticación.
Una declaración de atributo afirma que un principal está asociado con ciertos atributos. Un atributo es simplemente un par nombre-valor . Las partes dependientes utilizan atributos para tomar decisiones de control de acceso.
Una declaración de decisión de autorización afirma que a un principal se le permite realizar la acción A en el recurso R dada la evidencia E. La expresividad de las declaraciones de decisiones de autorización en SAML está intencionalmente limitada. Se recomienda que los casos de uso más avanzados utilicen XACML en su lugar.
Un protocolo SAML describe cómo ciertos elementos SAML (incluidas las aserciones) se empaquetan dentro de los elementos de solicitud y respuesta SAML, y brinda las reglas de procesamiento que las entidades SAML deben seguir al producir o consumir estos elementos. En su mayor parte, un protocolo SAML es un protocolo simple de solicitud-respuesta.
El tipo más importante de solicitud del protocolo SAML se denomina consulta . Un proveedor de servicios realiza una consulta directamente a un proveedor de identidad a través de un canal secundario seguro. Por tanto, los mensajes de consulta suelen estar vinculados a SOAP.
Correspondientes a los tres tipos de declaraciones, existen tres tipos de consultas SAML:
El resultado de una consulta de atributo es una respuesta SAML que contiene una aserción, que a su vez contiene una declaración de atributo. Consulte el tema SAML 2.0 para ver un ejemplo de consulta/respuesta de atributos .
Más allá de las consultas, SAML 1.1 no especifica otros protocolos.
SAML 2.0 amplía considerablemente la noción de protocolo . Los siguientes protocolos se describen en detalle en SAML 2.0 Core:
La mayoría de estos protocolos son nuevos en SAML 2.0 .
Un enlace SAML es una asignación de un mensaje de protocolo SAML a formatos de mensajería y/o protocolos de comunicaciones estándar. Por ejemplo, el enlace SAML SOAP especifica cómo se encapsula un mensaje SAML en un sobre SOAP, que a su vez está vinculado a un mensaje HTTP.
SAML 1.1 especifica solo un enlace, el enlace SAML SOAP. Además de SOAP, en el SSO del navegador web SAML 1.1 están implícitos los precursores del enlace HTTP POST, el enlace de redireccionamiento HTTP y el enlace de artefactos HTTP. Sin embargo, estos no están definidos explícitamente y solo se utilizan junto con el SSO del navegador web SAML 1.1. La noción de vinculación no se desarrolla completamente hasta SAML 2.0.
SAML 2.0 separa completamente el concepto de enlace del perfil subyacente. De hecho, existe una nueva especificación de enlaces en SAML 2.0 que define los siguientes enlaces independientes:
Esta reorganización proporciona una enorme flexibilidad: tomando solo el SSO del navegador web como ejemplo, un proveedor de servicios puede elegir entre cuatro enlaces (HTTP Redirect, HTTP POST y dos tipos de HTTP Artifact), mientras que el proveedor de identidad tiene tres opciones de enlace (HTTP POST más dos formas de artefacto HTTP), para un total de doce posibles implementaciones del perfil SSO del navegador web SAML 2.0.
Un perfil SAML describe en detalle cómo se combinan las aserciones, los protocolos y los enlaces SAML para admitir un caso de uso definido. El perfil SAML más importante es el perfil SSO del navegador web.
SAML 1.1 especifica dos formas de SSO del navegador web, el perfil de navegador/artefacto y el perfil de navegador/POST. Este último pasa afirmaciones por valor , mientras que Navegador/Artefacto pasa afirmaciones por referencia . Como consecuencia, Browser/Artifact requiere un intercambio SAML de canal secundario a través de SOAP. En SAML 1.1, todos los flujos comienzan con una solicitud al proveedor de identidad para simplificar. Se han propuesto extensiones patentadas al flujo básico iniciado por IdP (por Shibboleth , por ejemplo).
El perfil SSO del navegador web se refactorizó completamente para SAML 2.0. Conceptualmente, Navegador/Artefacto SAML 1.1 y Navegador/POST son casos especiales de SSO del Navegador Web SAML 2.0. Este último es considerablemente más flexible que su homólogo SAML 1.1 debido al nuevo diseño de enlace "plug-and-play" de SAML 2.0. A diferencia de las versiones anteriores, los flujos del navegador SAML 2.0 comienzan con una solicitud al proveedor de servicios. Esto proporciona una mayor flexibilidad, pero los flujos iniciados por SP naturalmente dan lugar al llamado problema de descubrimiento de proveedores de identidad , el foco de muchas investigaciones en la actualidad. Además del SSO del navegador web, SAML 2.0 introduce numerosos perfiles nuevos:
Además del perfil SSO del navegador web SAML, algunos perfiles de terceros importantes de SAML incluyen:
Las especificaciones SAML recomiendan, y en algunos casos exigen, una variedad de mecanismos de seguridad:
Los requisitos a menudo se expresan en términos de autenticación (mutua), integridad y confidencialidad, dejando la elección del mecanismo de seguridad a los implementadores y a los implementadores.
El caso de uso principal de SAML se denomina Inicio de sesión único (SSO) del navegador web . Un usuario utiliza un agente de usuario (normalmente un navegador web) para solicitar un recurso web protegido por un proveedor de servicios SAML . El proveedor de servicios, que desea conocer la identidad del usuario solicitante, emite una solicitud de autenticación a un proveedor de identidad SAML a través del agente de usuario. El flujo de protocolo resultante se muestra en el siguiente diagrama.
https://sp.example.com/myresourceEl proveedor de servicios realiza una verificación de seguridad en nombre del recurso de destino. Si ya existe un contexto de seguridad válido en el proveedor de servicios, omita los pasos 2 a 7.
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=requestEl valor del
SAMLRequestparámetro (indicado por el marcador de posición requestarriba) es la codificación Base64 de un elemento desinflado <samlp:AuthnRequest> .AuthnRequest(enviada a través del SAMLRequestparámetro de consulta URL) y realiza una verificación de seguridad. Si el usuario no tiene un contexto de seguridad válido, el proveedor de identidad identifica al usuario (se omiten detalles). < método de formulario = "publicar" acción = "https://sp.example.com/SAML2/SSO/POST" ... > < tipo de entrada = "oculto" nombre = "SAMLResponse" valor = "respuesta" /> ... < tipo de entrada = "enviar" valor = "Enviar" /> </ formulario > SAMLResponseelemento (indicado por el marcador de posición responsearriba) es la codificación base64 de un <samlp:Response>elemento.SAMLResponseparámetro se toma del formulario XHTML en el paso 4.https://sp.example.com/myresource
En SAML 1.1, el flujo comienza con una solicitud al servicio de transferencia entre sitios del proveedor de identidad en el paso 3.
En el flujo de ejemplo anterior, todos los intercambios representados son intercambios de canal frontal , es decir, un agente de usuario HTTP (navegador) se comunica con una entidad SAML en cada paso. En particular, no existen intercambios de canales secundarios ni comunicaciones directas entre el proveedor de servicios y el proveedor de identidad. Los intercambios de canal frontal conducen a flujos de protocolo simples donde todos los mensajes se pasan por valor mediante un enlace HTTP simple (GET o POST). De hecho, el flujo descrito en la sección anterior a veces se denomina perfil SSO del navegador web ligero .
Alternativamente, para mayor seguridad o privacidad, los mensajes pueden pasarse por referencia . Por ejemplo, un proveedor de identidad puede proporcionar una referencia a una aserción SAML (llamada artefacto ) en lugar de transmitir la aserción directamente a través del agente de usuario. Posteriormente, el proveedor de servicios solicita la afirmación real a través de un canal secundario. Dicho intercambio de canal secundario se especifica como un intercambio de mensajes SOAP (SAML sobre SOAP sobre HTTP). En general, cualquier intercambio SAML a través de un canal secundario seguro se realiza como un intercambio de mensajes SOAP.
En el canal posterior, SAML especifica el uso de SOAP 1.1. Sin embargo, el uso de SOAP como mecanismo de vinculación es opcional. Cualquier implementación SAML determinada elegirá los enlaces que sean apropiados.