stringtranslate.com

Lenguaje de marcado de aserción de seguridad

SAML ( Security Assertion Markup Language , 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]

Descripción general

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.

Historia

Historia de SAML (2002-2005)

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]

Versiones

SAML ha sufrido una revisión menor y una revisión importante desde la versión 1.0.

La Liberty Alliance aportó 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]

Diseño

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.

Afirmaciones

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:

  1. Declaraciones de autenticación
  2. Declaraciones de atributos
  3. Declaraciones de decisión de autorización

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.

Protocolos

Respuesta del protocolo SAML

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:

  1. Consulta de autenticación
  2. Consulta de atributos
  3. Consulta de decisión de autorización

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 .

Encuadernaciones

SAML sobre SOAP sobre HTTP

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.

Perfiles

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:

Seguridad

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.

Usar

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.

Inicio de sesión único mediante SAML en un navegador web
1. Solicitar el recurso de destino en el SP (solo SAML 2.0)
El principal (a través de un agente de usuario HTTPs) solicita un recurso de destino al proveedor de servicios:
https://sp.example.com/myresource
El 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.
2. Redirigir al servicio SSO en el IdP (solo SAML 2.0)
El proveedor de servicios determina el proveedor de identidad preferido del usuario (por medios no especificados) y redirige al agente de usuario al Servicio SSO en el proveedor de identidad:
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request
El valor del SAMLRequestparámetro (indicado por el marcador de posición requestanterior) es la codificación Base64 de un elemento desinflado <samlp:AuthnRequest> .
3. Solicitar el servicio SSO en el IdP (solo SAML 2.0)
El agente de usuario envía una solicitud GET al servicio SSO en la URL del paso 2. El servicio SSO procesa la solicitud 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).
4. Responder con un formulario XHTML
El servicio SSO valida la solicitud y responde con un documento que contiene un formulario XHTML:
 < 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 >   
El valor del SAMLResponseelemento (indicado por el marcador de posición responseanterior) es la codificación base64 de un <samlp:Response>elemento.
5. Solicitar la Afirmación del Servicio de Atención al Consumidor en el SP
El agente de usuario envía una solicitud POST al servicio de consumidor de aserciones del proveedor de servicios. El valor del SAMLResponseparámetro se toma del formato XHTML en el paso 4.
6. Redirigir al recurso de destino
El servicio de consumidor de aserciones procesa la respuesta, crea un contexto de seguridad en el proveedor de servicios y redirige al agente de usuario al recurso de destino.
7. Solicita nuevamente el recurso de destino en el SP
El agente de usuario solicita el recurso de destino al proveedor de servicios (nuevamente):
https://sp.example.com/myresource
8. Responder con el recurso solicitado
Dado que existe un contexto de seguridad, el proveedor de servicios devuelve el recurso al agente de usuario.

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.

Véase también

Referencias

  1. ^ "¿Qué es SAML? - Definición de una palabra del diccionario informático de Webopedia". Webopedia.com. 25 de junio de 2002. Consultado el 21 de septiembre de 2013 .
  2. ^ J. Hughes et al. Perfiles para el lenguaje de marcado de confirmación de seguridad (SAML) 2.0 de OASIS. Estándar OASIS, marzo de 2005. Identificador del documento: saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf (para consultar el último borrador de trabajo de esta especificación con erratas, consulte: https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf)
  3. ^ N. Ragouzis et al. Security Assertion Markup Language (SAML) 2.0 Technical Overview. Borrador 02 del Comité OASIS, marzo de 2008. Identificador del documento: sstc-saml-tech-overview-2.0-cd-02 https://wiki.oasis-open.org/security/Saml2TechOverview
  4. ^ "SAML: El secreto de la gestión centralizada de identidades". InformationWeek.com. 23 de noviembre de 2004. Consultado el 23 de mayo de 2014 .
  5. ^ Maler, Eve (9 de enero de 2001). "Acta de la teleconferencia de TC de Servicios de Seguridad del 9 de enero de 2001". security-services at oasis-open (Lista de correo) . Consultado el 7 de abril de 2011 .
  6. ^ "Historia de SAML". SAMLXML.org. 5 de diciembre de 2007. Consultado el 22 de mayo de 2014 .
  7. ^ Conor P. Cahill. "Liberty Technology Overview" (PDF) . Liberty Alliance . Consultado el 25 de agosto de 2017 .
  8. ^ abc "Google, NTT y la GSA de EE. UU. implementan SAML 2.0 para la gestión de identidad digital". Oracle Journal. 29 de enero de 2008. Consultado el 22 de mayo de 2014 .
  9. ^ P. Mishra; et al. (mayo de 2003), Diferencias entre OASIS Security Assertion Markup Language (SAML) V1.1 y V1.0 (PDF) , OASIS, sstc-saml-diff-1.1-draft-01 , consultado el 7 de abril de 2011
  10. ^ "Cómo romper el cifrado XML" (PDF) . Association for Computing Machinery . 19 de octubre de 2011 . Consultado el 31 de octubre de 2014 .
  11. ^ "Investigadores de la RUB rompen el estándar del W3C". Universidad del Ruhr, Bochum . 19 de octubre de 2011. Archivado desde el original el 24 de noviembre de 2011. Consultado el 29 de junio de 2012 .
  12. ^ SOAP 1.1

Enlaces externos