Entender SAML

SAML en 3 minutos

SAML permite iniciar sesión en una aplicación con la cuenta de su organización, sin que la aplicación vea nunca la contraseña.

Vea también: la línea de tiempo de la historia de SAML · la de OAuth y OpenID Connect

Una imagen para entender

Imagine un concierto. La aplicación es la sala: quiere saber quién entra, pero no comprueba usted mismo sus papeles. El proveedor de identidad es la oficina de acreditaciones de su empresa: conoce de verdad su identidad. A la entrada, la sala le envía a la oficina, que le entrega una credencial sellada con su nombre. La sala solo se fía del sello, que sabe reconocer.

Esta credencial sellada es la aserción SAML. El sello es la firma.

Los tres actores

Un inicio de sesión en cinco pasos

1. Usted abre la aplicación. Ve que no ha iniciado sesión.
2. Le envía a su proveedor de identidad con una solicitud: «identifica a esta persona y devuélvemela a esta dirección».
3. El proveedor de identidad le autentica (contraseña, aprobación en el teléfono…). Este paso solo ocurre en su lado.
4. Le devuelve a la aplicación con un mensaje firmado: la aserción (quién es usted, para qué aplicación, hasta cuándo).
5. La aplicación comprueba la firma y las condiciones, y luego abre una sesión para usted.

Qué contiene la aserción

• Quién: el identificador de la persona (el NameID, a menudo su correo).
• Para quién: la aplicación destinataria (la Audiencia) y la dirección de recepción exacta (el ACS).
• Hasta cuándo: un periodo de validez muy corto, unos minutos.
• Qué más: información sobre la persona (nombre, grupos…), llamada atributos.
• El sello: la firma, que prueba que el mensaje viene realmente del proveedor de identidad y no se ha modificado.

Por qué la aplicación confía en el mensaje

Antes de la primera prueba, la aplicación y el proveedor de identidad intercambian una especie de carnet de identidad técnico: los metadatos. Contienen sus nombres (Entity ID), sus direcciones y, sobre todo, el certificado que sirve para reconocer el sello. Es la parte de «configuración», y de ahí salen casi todos los problemas.

Qué configurar, en cada lado

Lado del proveedor de identidad	Lado de la aplicación
El nombre de la aplicación (Entity ID)	El nombre del proveedor de identidad (Entity ID)
La dirección a la que devolver a la persona (URL ACS)	La dirección a la que enviarles para que se identifiquen (SSO URL)
Opcionalmente, el certificado de la aplicación	El certificado del proveedor de identidad

Un error de un carácter (una barra final, http en lugar de https) basta para bloquearlo todo. ID-Kit le indica exactamente qué valor no coincide.

¿Y dónde encaja ID-Kit?

• ¿Tiene una aplicación que probar? ID-Kit hace de proveedor de identidad.
• ¿Tiene un proveedor de identidad que probar? ID-Kit hace de aplicación.

Para ir más lejos: el detalle técnico o los errores habituales.