SAML

El lenguaje de marcado de aserciones de seguridad ( SAML , pronunciado SAM-el , / ˈ s æ m əl / ) ^{[ 1 ]} es un estándar abierto para el intercambio de 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 aserciones de seguridad (declaraciones que los proveedores de servicios utilizan para tomar decisiones de control de acceso). SAML también es:

• Un conjunto de mensajes de protocolo basados ​​en XML
• Un conjunto de enlaces de mensajes de protocolo
• Un conjunto de perfiles (que utilizan todo lo anterior)

Un caso de uso importante que aborda SAML es el inicio de sesión único (SSO) en navegadores web . El inicio de sesión único es relativamente fácil de lograr dentro de un dominio de seguridad (usando cookies , por ejemplo), pero extenderlo a través de dominios de seguridad es más difícil y ha dado lugar a la proliferación de tecnologías propietarias no interoperables. El perfil SAML Web Browser SSO se especificó y estandarizó para promover la interoperabilidad. ^{[ 2 ]} En la práctica, SAML SSO se usa con mayor frecuencia para la autenticación en software empresarial basado en la nube. ^{[ 3 ]}

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 que contempla SAML, el principal solicita un servicio al proveedor de servicios. Este último solicita y obtiene una aserción de autenticación del proveedor de identidad. Con base en esta aserción, el proveedor de servicios puede tomar una decisión de control de acceso , es decir, decidir si presta o no el servicio al principal conectado.

En el núcleo de la aserción SAML se encuentra un sujeto (una entidad principal dentro del contexto de un dominio de seguridad específico) sobre el cual se realiza una afirmación. El sujeto suele ser (aunque no necesariamente) una persona. Como se indica en la  Descripción general técnica de SAML 2.0, ^{[ 4 ]} los términos sujeto y entidad principal se utilizan indistintamente.

Antes de entregar la aserción basada en el sujeto del Proveedor de Identidad al Proveedor de Servicios, el Proveedor de Identidad puede solicitar cierta información al principal (como un nombre de usuario y una contraseña) para autenticarlo. SAML especifica el contenido de la aserción que se transmite del Proveedor de Identidad al Proveedor de Servicios. En SAML, un Proveedor de Identidad puede proporcionar aserciones SAML a varios Proveedores de Servicios. Del mismo modo, un Proveedor de Servicios (SP) puede confiar en las aserciones de varios Proveedores de Identidad (IdP) independientes. ^{[ 5 ]}

SAML no especifica el método de autenticación del proveedor de identidad. El IdP puede usar un nombre de usuario y una contraseña, u otra forma de autenticación, incluyendo la autenticación multifactor o los tickets Kerberos . Un servicio de directorio como RADIUS o LDAP , 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. ^{[ 6 ]} Los servicios populares de redes sociales de Internet también proporcionan servicios de identidad que, en teoría, podrían usarse para admitir 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 constituido para "definir un marco XML para el intercambio de información de autenticación y autorización". ^{[ 7 ]} Con este fin, se aportó la siguiente propiedad intelectual al SSTC durante los dos primeros meses de ese año:

• Lenguaje de marcado de servicios de seguridad (S2ML) de Netegrity
• AuthXML de Securant
• Especificación del Servicio de Aserción de Confianza XML (X-TASS) de VeriSign
• Lenguaje de marcado de tecnología de la información (ITML) de Jamcracker

Partiendo de estas contribuciones iniciales, en noviembre de 2002 OASIS anunció la  especificación Security Assertion Markup Language (SAML) 1.0 como un estándar de OASIS. ^{[ 8 ]}

Mientras tanto, Liberty Alliance , un gran consorcio de empresas, organizaciones sin fines de lucro y gubernamentales, propuso una extensión del estándar SAML denominada Liberty Identity Federation Framework (ID-FF). ^{[ 9 ]} Al igual que su predecesor SAML, Liberty ID-FF propuso un marco estandarizado, multidominio y basado en la web para el inicio de sesión único. Además, Liberty describió un círculo de confianza donde 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 entonces examinar estas políticas para determinar si confían en dicha información. ^{[ 10 ]}

Mientras Liberty desarrollaba ID-FF, el 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 , sentando así las bases 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 las 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 versión 2.0, mientras que muchas aún son compatibles con la versión 1.1 por motivos de retrocompatibilidad. Para enero de 2008, las implementaciones de SAML  2.0 se habían generalizado en el gobierno, la educación superior y las empresas comerciales de todo el mundo. ^{[ 10 ]}

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

• SAML  1.0 fue adoptado como estándar OASIS en noviembre de 2002.
• SAML 1.1 fue ratificado como estándar OASIS en septiembre de 2003.
• SAML 2.0 se convirtió en un estándar OASIS en marzo de 2005.

La Liberty Alliance aportó su Marco de Federación de Identidad (ID-FF) al OASIS SSTC en septiembre de 2003:

• ID-FF  1.1 se lanzó en abril de 2003.
• La versión ID-FF  1.2 se finalizó en noviembre de 2003.

Las versiones 1.0 y 1.1 de SAML son similares, aunque existen pequeñas diferencias ^{[ 11 ]} . Sin embargo, las diferencias entre SAML  2.0 y SAML  1.1 son sustanciales. Si bien ambos estándares abordan el mismo caso de uso, SAML  2.0 es incompatible con su predecesor.

Aunque ID-FF  1.2 se aportó 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. ^{[ 10 ]}

SAML se basa en una serie de estándares existentes:

• Lenguaje de marcado extensible (XML): La mayoría de los intercambios SAML se expresan en un dialecto estandarizado de XML, que es la raíz del nombre SAML (Security Assertion Markup Language).
• Esquema XML (XSD): Las aserciones y los protocolos SAML se especifican (en parte) mediante un esquema XML.
• Firma XML : Tanto SAML 1.1 como SAML 2.0 utilizan firmas digitales (basadas en el estándar de firma XML) para la autenticación y la integridad de los mensajes.
• Cifrado XML : Mediante el cifrado XML, SAML 2.0 proporciona elementos para identificadores de nombre cifrados, atributos cifrados y aserciones cifradas (SAML  1.1 no dispone de capacidades de cifrado). Se ha informado de que el cifrado XML presenta graves problemas de seguridad. ^{[ 12 ] [ 13 ]}
• Protocolo de transferencia de hipertexto (HTTP): SAML depende en gran medida de HTTP como su protocolo de comunicación.
• Protocolo simple de acceso a objetos (SOAP) : SAML especifica el uso de SOAP, específicamente SOAP 1.1. ^{[ 14 ]}

SAML define aserciones, protocolos, enlaces y perfiles basados ​​en XML. El término SAML Core se refiere a la sintaxis y semántica generales de las aserciones SAML, así como al protocolo utilizado para solicitar y transmitir dichas aserciones entre entidades del sistema. El protocolo SAML se refiere a lo que se transmite, no a cómo (esto último viene determinado por la elección del enlace). Por lo tanto, SAML Core define las aserciones SAML básicas junto con los elementos de solicitud y respuesta SAML.

Un enlace SAML determina cómo las solicitudes y respuestas SAML se corresponden con los protocolos de mensajería o comunicación 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.

<saml:Aserción ...> ... </saml:Asertion>

Protocolos

Un protocolo SAML describe cómo se empaquetan ciertos elementos SAML (incluidas las aserciones) dentro de los elementos de solicitud y respuesta SAML, y establece las reglas de procesamiento que las entidades SAML deben seguir al producir o consumir estos elementos. En general, 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 comunicación seguro. Por lo tanto, los mensajes de consulta suelen estar vinculados al protocolo 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, la cual 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:

• Protocolo de consulta y solicitud de aserción
• Protocolo de solicitud de autenticación
• Protocolo de resolución de artefactos
• Protocolo de gestión de identificadores de nombre
• Protocolo de cierre de sesión único
• Protocolo de mapeo de identificadores de nombre

La mayoría de estos protocolos son nuevos en SAML 2.0 .

Encuadernaciones

Un enlace SAML es una asignación de un mensaje del protocolo SAML a formatos de mensajería o protocolos de comunicación 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 un único enlace: el enlace SAML SOAP. Además de SOAP, el inicio de sesión único (  SSO) del navegador web de SAML 1.1 incluye implícitamente los precursores del enlace HTTP POST, el enlace HTTP Redirect y el enlace HTTP Artifact. Sin embargo, estos no se definen explícitamente y solo se utilizan junto con  el SSO del navegador web de SAML 1.1. El concepto de enlace no se desarrolla completamente hasta SAML  2.0.

SAML  2.0 separa completamente el concepto de enlace del perfil subyacente. De hecho, SAML  2.0 incluye una especificación de enlace totalmente nueva que define los siguientes enlaces independientes:

• Enlace SAML SOAP (basado en SOAP  1.1)
• Enlace SOAP inverso (PAOS)
• Enlace de redirección HTTP (GET)
• Enlace HTTP POST
• Enlace de artefactos HTTP
• Enlace de URI SAML

Esta reorganización proporciona una enorme flexibilidad: tomando como ejemplo únicamente el inicio de sesión único (SSO) del navegador web, un proveedor de servicios puede elegir entre cuatro enlaces (redirección HTTP, HTTP POST y dos variantes 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 SAML 2.0 de SSO del navegador web.

El caso de uso principal de SAML se denomina Inicio de sesión único (SSO) mediante 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, con el fin de conocer la identidad del usuario solicitante, envía una solicitud de autenticación a un proveedor de identidad SAML a través del agente de usuario. El flujo del protocolo resultante se muestra en el siguiente diagrama.

1. Solicitar el recurso de destino en el SP (solo SAML  2.0)

El usuario principal (a través de un agente de usuario HTTPS) solicita un recurso específico 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 del 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 deflactado .<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 mediante el SAMLRequestparámetro de consulta de la URL) y realiza una comprobación de seguridad. Si el usuario no tiene un contexto de seguridad válido, el proveedor de identidad lo identifica (detalles omitidos).

4. Responda con un formulario XHTML.

El servicio SSO valida la solicitud y responde con un documento que contiene un formulario XHTML:

< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> ... < input type = "submit" value = " Enviar" / > </form>

El valor del SAMLResponseelemento (indicado por el marcador de posición responseanterior) es la codificación base64 de un <samlp:Response>elemento.

5. Solicite el Servicio de Atención al Consumidor de Reclamaciones 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 obtiene del formulario 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. Solicitar nuevamente el recurso objetivo en el SP.

El agente de usuario solicita el recurso de destino al proveedor de servicios (de nuevo):

https://sp.example.com/myresource

8. Responda 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 ejemplo de flujo anterior, todos los intercambios representados son 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 dan lugar a flujos de protocolo simples donde todos los mensajes se transmiten por valor mediante un enlace HTTP simple (GET o POST). De hecho, el flujo descrito en la sección anterior se conoce a veces como Perfil SSO ligero para navegador web .

Como alternativa, para mayor seguridad o 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 transmitirla directamente a través del agente de usuario. Posteriormente, el proveedor de servicios solicita la aserción real mediante un canal de retorno. Este intercambio a través de un 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 realiza como un intercambio de mensajes SOAP.

En el canal secundario, SAML especifica el uso de SOAP  1.1. Sin embargo, el uso de SOAP como mecanismo de enlace es opcional. Cada implementación de SAML elegirá los enlaces que considere apropiados.

• SAML 2.0
• metadatos SAML
• Productos y servicios basados ​​en SAML
• Gestión de identidades
• Sistemas de gestión de identidades
• Identidad federada
• Tarjeta informativa
• WS-Federation
• OAuth
• OpenID Connect

• Comité Técnico de Servicios de Seguridad de OASIS
• Portada: Lenguaje de marcado de aserciones de seguridad (SAML)
• Cómo estudiar y aprender SAML
• Desmitificando SAML
• Primer proveedor público de identidad SAML 2.0
• Daniel Blum (2003). La identificación federada cobra impulso . IDG Network World Inc. pág.  42.