SAML

SAML (Security Assertion Markup Language) es un estándar abierto para la autenticación y autorización de usuarios. Permite que un sistema (generalmente un sitio web o aplicación) delegue el inicio de sesión a otro sistema de confianza (como el login corporativo de la empresa).

LDAP y SAML parecen cubrir el mismo terreno, pero resuelven problemas diferentes y complementarios.

LDAP (Lightweight Directory Access Protocol) es un protocolo de consulta de directorios. Se utiliza para autenticar usuarios (ej: login con usuario/contraseña) y buscar información (ej: grupos, permisos), pero es de más bajo nivel, es decir, una aplicación que usa LDAP necesita saber cómo conectarse, cómo autenticar, cómo manejar sesiones y contraseñas, etc.

Característica	LDAP	SAML
Tipo	Protocolo de directorio	Protocolo de federación de identidad
Transporte	TCP (cliente → servidor)	Navegador (redirects vía HTTP)
Autenticación	Directa (usuario/contraseña)	Indirecta (vía assertion del IdP)
Integración	Cada app necesita hablar LDAP	Apps solo necesitan aceptar SAML
SSO (Single Sign-On)	No nativo	Sí, diseñado para eso
Contraseña	Aplicación ve y manipula contraseña	Contraseña nunca llega a la aplicación

¿Qué resuelve SAML que LDAP no resuelve?

• SSO (Single Sign-On): LDAP no tiene concepto de login único. Cada app que usa LDAP necesita pedir usuario y contraseña cada vez. Con SAML, un único login sirve para varias apps.
• Menor exposición de contraseña: Con LDAP, la app necesita la contraseña para autenticar al usuario. Con SAML, ninguna contraseña se envía a la app — solo una assertion firmada.
• Federar identidad entre dominios: Con SAML, puedes iniciar sesión en apps de terceros (ej: Salesforce, AWS, etc.) usando tu login corporativo. LDAP no escala bien para eso.
• Basado en navegador: SAML está hecho para funcionar 100% vía navegador. Ideal para apps web modernas. LDAP necesita bibliotecas, binds, conexiones TCP, etc.

LDAP es como una base de datos de usuarios que tú mismo consultas y autentificas.

SAML es como una "declaración de confianza" que viene de un organismo confiable (el IdP), diciendo "este usuario está autenticado".

Redirecciones HTTP

Esta es la idea base de cómo funciona SAML.

Imaginemos que tenemos una aplicación Web 1 que necesita comunicarse con otra aplicación web 2, pero la aplicación web 1 está dentro de la intranet de la empresa mientras que la 2 está fuera y no tiene acceso a la aplicación web 1.

Podemos aprovechar el navegador para hacer esto si tiene acceso a ambas. El equipo del usuario está en la VPN de la empresa y consigue acceso a la aplicación. Caso la aplicación web 2 necesite comunicarse con la 1, puede enviar una solicitud para que el navegador haga la petición por ella. Lo mismo puede suceder con la aplicación web 1 intentando comunicarse con la 2.

Toda esta redirección ocurre vía HTTP request con reenvíos en la cabecera de la solicitud.

Flujo de Autenticación

A continuación el flujo de cómo ocurre la prueba de identidad usando SAML.

En el proceso 4, caso el usuario ya esté logueado entonces reutiliza el login en vez de pedir una nueva autenticación, mejorando el flujo y disminuyendo el número de llamadas. Si el navegador ya tiene una cookie de sesión activa y válida no pedirá login de nuevo. Genera la respuesta SAML (SAMLResponse) y te redirige de vuelta al SP.

Incluso si la cookie de sesión es válida el login aún ocurre, pero de forma transparente y mucho más rápida. El IdP llega a hacer la petición al IdP en el paso 3. El IdP verifica la cookie en la solicitud y con la cookie válida no muestra la pantalla de login pero genera el SAMLResponse en el paso 4 redirigiendo de vuelta al SP.

El SAMLResponse es el corazón del SAML SSO — es donde el IdP prueba al SP que estás autenticado. Es un XML firmado digitalmente, conteniendo algo de este tipo.

<samlp:Response>
  <saml:Issuer>https://idp.ejemplo.com</saml:Issuer>
  <samlp:Status>...</samlp:Status>
  <saml:Assertion>
    <saml:Subject>
      <saml:NameID>[email protected]</saml:NameID>
      ...
    </saml:Subject>
    <saml:Conditions>...</saml:Conditions>
    <saml:AuthnStatement>...</saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="email">...</saml:Attribute>
      <saml:Attribute Name="role">...</saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Campo	Qué hace
Issuer	Quién generó la respuesta (el IdP)
Status	Si la autenticación fue exitosa
Assertion	La prueba de que el usuario está autenticado
NameID	Identificador del usuario (generalmente email o username)
AuthnStatement	Cuándo y cómo el usuario se autenticó
AttributeStatement	Info adicional (ej: nombre, email, grupos, cargo, etc)
Conditions	Validez de la respuesta, SP autorizado, etc
Signature	Firma digital que garantiza la integridad y autenticidad

¿Qué hace el SP con esto?

• Verifica la firma.
• Comprueba si el Issuer es confiable.
• Lee el NameID y los atributos.
• Crea una sesión local para el usuario.

SAMLResponse = respuesta completa del IdP.

SAML Assertion = la parte de la respuesta que contiene la identidad y los atributos del usuario.

"SAML token" = otro nombre para ese Assertion (a veces llamado "token SAML" porque es lo que "prueba" la identidad).

<samlp:Response>
  ...
  <saml:Assertion>  ← ESTO es el "SAML token"
    <saml:Subject>...</saml:Subject>
    <saml:AuthnStatement>...</saml:AuthnStatement>
    <saml:AttributeStatement>...</saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

¿Cómo podemos tener certeza de que el SAMLResponse vino realmente del IdP y no fue falsificado?

Para eso, usamos firma digital + intercambio previo de certificados.

Al configurar la aplicación, es necesario establecer una relación de confianza con el IdP.

El IdP posee un certificado X.509 (conteniendo su clave pública), que debe ser conocido por el SP. Este certificado puede ser proporcionado manualmente o vía metadata XML. Normalmente, el IdP dispone estos metadatos (incluyendo el certificado) en un endpoint público, permitiendo que el SP actualice la información automáticamente caso ocurran cambios. Estos datos no son sensibles, por eso pueden ser expuestos públicamente.

Cuando el SAMLResponse llega al SP, usa la clave pública del IdP para verificar la firma digital contenida en la respuesta. Esto garantiza que el contenido no fue alterado ni falsificado durante el trayecto.

Si es necesario lee más sobre esto en TLS.

Con todo esto, conseguimos centralizar los usuarios en un único lugar y trabajar con Single Sign-On (SSO).

Estos usuarios pasan a ser considerados federados, es decir, sus identidades son gestionadas por un proveedor central (IdP) y pueden ser usadas por varias aplicaciones dentro de la organización. Esto permite que todos los sistemas compartan la misma identidad de forma segura y estandarizada.

¿Cuáles son las limitaciones de SAML?

A pesar de ser un estándar muy usado, especialmente en empresas, SAML tiene algunas limitaciones importantes:

1. Complejidad: El protocolo es verboso (XML pesado, namespaces, firma digital, etc). Implementar correctamente requiere mucha atención a detalles técnicos.

2. Rendimiento: Basado en XML e intercambio de datos vía redirects HTTP + base64, lo que puede ser más lento comparado con soluciones modernas como OAuth2/OIDC.

3. Limitado a Web: Fue creado para navegadores y aplicaciones web. No funciona bien en APIs o apps móviles. No maneja bien tokens bearer como el JWT.

4. Sesión gestionada por el IdP: El SP depende del IdP para todo relacionado con la sesión. Esto limita el control que el SP tiene sobre logout, expiración, etc.

5. Integraciones más difíciles: Configurar SAML entre SP e IdP suele ser manual y tedioso (intercambio de metadata, certificados, endpoints). Pocos servicios ofrecen un SDK simple como OAuth2/OIDC.

6. Fallos comunes de implementación: Por ser complejo, muchos desarrolladores se equivocan en la verificación de firma, replay attacks, o aceptan assertions vencidas.

SAML aún es útil, especialmente en entornos corporativos heredados, pero está siendo gradualmente sustituido por OIDC/OAuth2, que son más ligeros, modernos y versátiles.