Decodificador de SAMLResponse y SAMLRequest

Cómo decodificar un mensaje SAML

1. Pega lo que tengas. Todo esto funciona:
   • el valor SAMLResponse o SAMLRequest solo, con o sin codificación URL
   • SAMLRequest=… con o sin RelayState, SigAlg y Signature
   • una URL Redirect completa copiada de la barra de direcciones
   • el formulario HTML de envío automático con el input oculto SAMLResponse
   • XML en bruto
2. El decodificador detecta el binding: Base64 simple significa HTTP-POST; datos comprimidos con deflate, HTTP-Redirect.
3. Lee primero el resumen y después el XML formateado que hay debajo. El XML se muestra como texto y nunca se renderiza.

La dirección Codificar hace lo contrario: pega un AuthnRequest y obtén un valor Redirect, un parámetro SAMLRequest= o una URL completa construida a partir del atributo Destination. Viene bien para repetir una petición mientras pruebas un proveedor de servicios.

Binding Redirect frente a binding POST

Redirect usa compresión porque las URL tienen límites de longitud en la práctica. En el ejemplo de esta página, un AuthnRequest de 464 caracteres se comprime a 273 bytes y viaja como 364 caracteres Base64. Las respuestas llevan firmas y certificados, así que son demasiado grandes para una URL y van por POST. El decodificador también acepta datos con envoltorio zlib, que algunos proveedores de servicios envían por Redirect en lugar de raw deflate.

Qué revisar cuando falla el SSO

El resumen extrae los campos que causan la mayoría de los fallos de inicio de sesión:

• Estado: cualquier cosa que no sea urn:oasis:names:tc:SAML:2.0:status:Success. Un subcódigo como AuthnFailed, InvalidNameIDPolicy o RequestDenied indica el motivo, y StatusMessage suele añadir detalles.
• Destination y URL ACS: deben coincidir exactamente con el endpoint configurado en el proveedor de servicios, incluidos https y la barra final.
• Audiencia: debe ser igual al entity ID del SP. Un desajuste aquí es un error de configuración frecuente después de renombrar una aplicación.
• Condiciones: NotBefore y NotOnOrAfter se comparan con tu reloj. Un «caducado» o «aún no válido» en un inicio de sesión recién hecho apunta a un desfase de reloj entre el IdP y el SP.
• InResponseTo: debe ser igual al ID del AuthnRequest. Si no coincide, la respuesta es antigua o se ha reenviado. El atributo no aparece en los inicios de sesión iniciados por el IdP, que algunos proveedores de servicios rechazan.
• NameID y Format: el identificador que el SP comparará con sus usuarios, por ejemplo emailAddress frente a persistent.
• Atributos: cada atributo con todos sus valores, para confirmar que el IdP envía los grupos o el email que el SP mapea.

Decodificar SAML en Python

import base64, zlib
from urllib.parse import unquote

def decode_post(value):
    return base64.b64decode(value).decode()

def decode_redirect(value):
    raw = base64.b64decode(unquote(value))
    return zlib.decompress(raw, -15).decode()

El -15 le dice a zlib que espere raw deflate sin encabezado. Llama a unquote solo con valores copiados de una URL; un valor de un formulario POST ya es Base64 simple, y decodificarlo como URL puede convertir + en un espacio. Hay más en Base64 en Python, y la parte de la compresión se explica en la página de raw deflate y zlib.

Privacidad de las aserciones SAML

Una aserción contiene nombres, direcciones de email, pertenencia a grupos y a veces más datos personales, y una válida que no ha caducado puede servir como token de inicio de sesión. Esta página la decodifica en local y no puede enviarla a ninguna parte. Aun así, censura las aserciones antes de pegarlas en tickets o chats, y trata una respuesta capturada como una cookie de sesión hasta que haya pasado su NotOnOrAfter.

Preguntas frecuentes