Aserción de seguridad Markup Language ( SAML , pronunciado SAM-el , / s æ m əl / ) [1] es un estándar abierto para el intercambio de autenticación y de autorización de datos 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) del 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 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 (generalmente 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 del proveedor de servicios. El proveedor de servicios solicita y obtiene una aserció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 corazón de la aserción SAML hay un sujeto (un principal dentro del contexto de un dominio de seguridad particular) sobre el cual se está afirmando algo. El sujeto suele ser (pero no necesariamente) un ser humano. Al igual que en la descripción general técnica de SAML V2.0, [3] los términos asunto y principal se utilizan indistintamente en este documento.
Antes de entregar la afirmación basada en el sujeto 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 pasa 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 y confiar en las afirmaciones de muchos IdP independientes.
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 de múltiples factores . 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 de OASIS (SSTC), que se reunió por primera vez en enero de 2001, fue creado "para definir un marco XML para el intercambio de información de autenticación y autorización". [5] Con este fin, se aportó a la CSST la siguiente propiedad intelectual durante los dos primeros meses de ese año:
Sobre la base de estas contribuciones iniciales, en noviembre de 2002 OASIS anunció la especificación Security Assertion Markup Language (SAML) V1.0 como estándar 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, entre dominios, basado en la web. Además, Liberty describió un círculo de confianza en el que se confía en cada dominio participante para documentar con precisión los procesos utilizados para identificar a un usuario, el tipo de sistema de autenticación utilizado y las políticas asociadas con las credenciales de autenticación resultantes. Otros miembros del círculo de confianza podrían examinar estas políticas para determinar si deben confiar en dicha información. [8]
Mientras Liberty estaba desarrollando ID-FF, el SSTC comenzó a trabajar en una actualización menor al estándar SAML. La especificación SAML V1.1 resultante fue ratificada por la 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, SAML V2.0 se anunció como estándar OASIS. SAML V2.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 V2.0, mientras que muchas aún admiten V1.1 para compatibilidad con versiones anteriores. En enero de 2008, las implementaciones de SAML V2.0 se volvieron comunes en empresas gubernamentales, de educación superior y comerciales de todo el mundo. [8]
SAML se ha sometido a una revisión menor y otra mayor desde la V1.0.
Liberty Alliance contribuyó con su Identity Federation Framework (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 sus raíces comunes, son incompatibles. [8]
SAML se basa en una serie de estándares existentes:
SAML define aserciones y protocolos, enlaces y perfiles basados en XML. El término SAML Core se refiere a la sintaxis general y la semántica 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 (este último está determinado por la elección de la vinculación). Por lo tanto, SAML Core define aserciones SAML "desnudas" junto con elementos de solicitud y respuesta SAML.
Un enlace SAML determina cómo las solicitudes y respuestas SAML se asignan a los protocolos estándar de mensajería o comunicaciones. Un enlace importante (sincrónico) es el enlace SAML SOAP.
Un perfil SAML es una manifestación concreta de un caso de uso definido utilizando una combinación particular de aserciones, protocolos y enlaces.
Una aserción SAML contiene un paquete de información de seguridad:
<saml: Afirmació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 generalmente se transfieren 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 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 ser revelada 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 decisión de autorización afirma que un director se le permite realizar la acción A en el recurso R evidencia dada E . La expresividad de las declaraciones de decisión de autorización en SAML está intencionalmente limitada. Se recomienda a los casos de uso más avanzados que 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 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 y respuesta.
El tipo más importante de solicitud de protocolo SAML se llama consulta . Un proveedor de servicios realiza una consulta directamente a un proveedor de identidad a través de un canal de respaldo 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 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 un mapeo de un mensaje de protocolo SAML en formatos de mensajería estándar y / o protocolos de comunicaciones. 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 SAML SOAP. Además de SOAP, implícitos en SAML 1.1 Web Browser SSO están los precursores de HTTP POST Binding, HTTP Redirect Binding y HTTP Artifact Binding. Sin embargo, no se definen explícitamente y solo se utilizan junto con el SSO del navegador web SAML 1.1. La noción de vinculación no está completamente desarrollada hasta SAML 2.0.
SAML 2.0 separa completamente el concepto de vinculación del perfil subyacente. De hecho, existe una nueva especificación de enlace 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 plus dos formas de HTTP Artifact), para un total de doce (12) posibles implementaciones del perfil SSO del navegador web SAML 2.0.
Un perfil SAML describe en detalle cómo las aserciones, protocolos y enlaces SAML se combinan 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 del navegador / artefacto y el perfil del navegador / POST. Este último pasa aserciones por valor, mientras que Browser / Artifact pasa aserciones por referencia . Como consecuencia, Browser / Artifact requiere un intercambio SAML de canal posterior sobre 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ó por completo para SAML 2.0. Conceptualmente, SAML 1.1 Browser / Artifact y Browser / POST son casos especiales de SAML 2.0 Web Browser SSO. 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 de proveedores de identidad , el foco de muchas investigaciones 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 expresan 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 llama Inicio de sesión único (SSO) del navegador web . Un usuario utiliza un agente de usuario (generalmente un navegador web) para solicitar un recurso web protegido por un proveedor de servicios SAML . El proveedor de servicios, deseando 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
SAMLRequest
parámetro (indicado por el marcador de posición request
anterior) es la codificación Base64 de un elemento desinflado <samlp:AuthnRequest>
.AuthnRequest
(enviado a través del SAMLRequest
pará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 los detalles). < form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> ... < input type = "submit" value = "Submit" /> </ form >
SAMLResponse
elemento (indicado por el marcador de posición response
anterior) es la codificación base64 de un <samlp:Response>
elemento.SAMLResponse
pará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 hay intercambios de canal de retorno 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 SSO del navegador web ligero .
Alternativamente, para mayor seguridad o privacidad, los mensajes se pueden pasar 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 de retorno. Dicho intercambio de canal de retorno se especifica como un intercambio de mensajes SOAP (SAML sobre SOAP sobre HTTP). En general, cualquier intercambio de SAML a través de un canal de respaldo 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 de SAML determinada elegirá los enlaces que sean apropiados.