Security Assertion Markup Language ( 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 los proveedores de servicios utilizan 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 otros 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 afirmación SAML se encuentra 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. Como 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 una contraseña) para autenticar al principal. SAML especifica el contenido de la aserción que se transmite del IdP al SP. En SAML, un proveedor de identidad puede proporcionar aserciones SAML a muchos proveedores de servicios. De manera similar, un SP puede confiar en las aserciones de muchos IdP independientes. [ cita requerida ]
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 una 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 Estándares de Información Estructurada (OASIS) , que se reunió por primera vez en enero de 2001, fue creado "para definir un marco XML para intercambiar información de autenticación y autorización". [5] Con este fin, durante los dos primeros meses de ese año se aportó al 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 OASIS. [6]
Mientras tanto, Liberty Alliance , un gran consorcio de empresas, organizaciones sin fines de lucro y gubernamentales, 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 y basado en la 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 confiar en dicha información. [8]
Mientras Liberty estaba desarrollando ID-FF, el SSTC comenzó a trabajar en una pequeña actualización 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 siguiente versión principal de SAML. En marzo de 2005, SAML 2.0 se anunció como estándar OASIS. SAML 2.0 representa la convergencia de Liberty ID-FF y extensiones propietarias aportadas por el proyecto Shibboleth , así como las primeras versiones del propio SAML. La mayoría de las implementaciones de SAML son compatibles con la v2.0, mientras que muchas aún son compatibles con la v1.1 para 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 experimentado una revisión menor y una revisión importante desde la versión 1.0.
La 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 incorporó 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 sus raíces comunes, son incompatibles. [8]
SAML se basa en una serie de estándares existentes:
SAML define aserciones y protocolos basados en XML, enlaces y perfiles. El término SAML Core hace referencia a la sintaxis y semántica generales de las aserciones SAML, así como al protocolo utilizado para solicitar y transmitir dichas aserciones de una entidad del sistema a otra. El protocolo SAML se refiere a lo que se transmite, no a cómo (esto último se determina mediante 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 se asignan las solicitudes y respuestas SAML a los protocolos de mensajería o comunicación estándar. Un enlace (sincrónico) importante es el enlace SOAP SAML.
Un perfil SAML es una manifestación concreta de un caso de uso definido que utiliza una combinación particular de afirmaciones, protocolos y enlaces.
Una afirmación SAML contiene un paquete de información de seguridad:
<saml:Afirmación ...> .. </saml:Afirmació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 suelen transferirse de los proveedores de identidad a los proveedores de servicios. Las afirmaciones 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 le afirman al proveedor de servicios que el principal efectivamente se autenticó con el proveedor de identidad en un momento particular utilizando un método de autenticación particular. Otra información sobre el principal autenticado (llamado contexto de autenticación ) puede revelarse 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 que confían utilizan atributos para tomar decisiones de control de acceso.
Una declaración de decisión de autorización afirma que se permite a un principal realizar la acción A sobre el recurso R dada la evidencia E. La expresividad de las declaraciones de decisión de autorización en SAML está limitada intencionalmente. Se recomienda que los casos de uso más avanzados utilicen XACML en su lugar.
Un protocolo SAML describe cómo se empaquetan determinados elementos SAML (incluidas las aserciones) dentro de los elementos de solicitud y respuesta SAML, y proporciona 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 de retorno seguro. Por lo tanto, los mensajes de consulta suelen estar vinculados a SOAP.
En correspondencia con 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 atributo .
Más allá de las consultas, SAML 1.1 no especifica ningún otro protocolo.
SAML 2.0 amplía considerablemente el concepto 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 estándar y/o protocolos de comunicación. Por ejemplo, el enlace SAML SOAP especifica cómo se encapsula un mensaje SAML en un sobre SOAP, que a su vez está enlazado a un mensaje HTTP.
SAML 1.1 especifica solo un enlace, el enlace SOAP de SAML. Además de SOAP, en el SSO de navegador web de SAML 1.1 están implícitos los precursores del enlace HTTP POST, el enlace de redireccionamiento HTTP y el enlace de artefacto HTTP. Sin embargo, no están definidos explícitamente y solo se utilizan junto con el SSO de navegador web de SAML 1.1. El concepto de enlace no se desarrolla por completo hasta SAML 2.0.
SAML 2.0 separa por completo el concepto de vinculación del perfil subyacente. De hecho, hay una nueva especificación de vinculación en SAML 2.0 que define las siguientes vinculaciones 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 (redirección HTTP, HTTP POST y dos formas de artefacto HTTP), 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 respaldar un caso de uso definido. El perfil SAML más importante es el perfil de inicio de sesión único del navegador web.
SAML 1.1 especifica dos formas de inicio de sesión único (SSO) del navegador web: el perfil de navegador/artefacto y el perfil de navegador/POST. Este último pasa las afirmaciones por valor , mientras que el perfil de navegador/artefacto pasa las afirmaciones por referencia . Como consecuencia, el perfil de navegador/artefacto 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 propietarias del flujo básico iniciado por el IdP (por Shibboleth , por ejemplo).
El perfil de SSO del navegador web se refactorizó por completo para SAML 2.0. Conceptualmente, SAML 1.1 Browser/Artifact y Browser/POST son casos especiales de SSO del navegador web de SAML 2.0. Este último es considerablemente más flexible que su contraparte 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 del proveedor de identidad , el foco de mucha investigación en la actualidad. Además del SSO del navegador web, SAML 2.0 presenta 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 formulan en términos de autenticación (mutua), integridad y confidencialidad, dejando la elección del mecanismo de seguridad a los implementadores y desplegadores.
El caso de uso principal de SAML se denomina inicio de sesión único (SSO) en el 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 comprobació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 requestanterior) es la codificación Base64 de un elemento desinflado <samlp:AuthnRequest> .AuthnRequest(enviada a través del SAMLRequestparámetro de consulta de URL) y realiza una comprobación de seguridad. Si el usuario no tiene un contexto de seguridad válido, el proveedor de identidad identifica al usuario (se omiten los 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 responseanterior) es la codificación base64 de un <samlp:Response>elemento.SAMLResponseparámetro se toma del formato 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 hay intercambios de canal posterior 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 utilizando un enlace HTTP simple (GET o POST). De hecho, el flujo descrito en la sección anterior a veces se denomina perfil de inicio de sesión único de navegador web ligero .
Como alternativa, para aumentar la seguridad o la privacidad, los mensajes pueden transmitirse por referencia . Por ejemplo, un proveedor de identidad puede proporcionar una referencia a una aserción SAML (denominada artefacto ) en lugar de transmitir la aserción directamente a través del agente de usuario. Posteriormente, el proveedor de servicios solicita la aserción real a través de un canal de retorno. Este intercambio de canal de retorno se especifica como un intercambio de mensajes SOAP (SAML sobre SOAP sobre HTTP). En general, cualquier intercambio SAML a través de un canal de retorno seguro se lleva a cabo 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 enlace es opcional. Cualquier implementación de SAML elegirá los enlaces que sean apropiados.