Decodificador SAML
Pega un SAMLResponse, un SAMLRequest, una URL de redirección o un cuerpo POST. El decodificador detecta la codificación (URL, base64, DEFLATE), muestra el XML formateado y extrae el usuario, los atributos, la audiencia, las firmas y todos los periodos de validez, comprobados con tu reloj. Nada sale de tu navegador.
Última actualización:
Cómo usar Decodificador SAML
- Copia el mensaje SAML desde las herramientas para desarrolladores de tu navegador (pestaña Red, el POST a la URL ACS o la redirección al IdP) o desde una extensión SAML tracer.
- Pégalo en el cuadro: sirve solo el valor, la URL completa o el cuerpo del formulario.
- Lee el resumen para ver quién lo emitió, para qué usuario es, el estado y los atributos.
- Comprueba los periodos de validez; ajusta el desfase de reloj que permite tu proveedor de servicios si el problema son errores de tiempo.
- Copia el XML o cambia a Codificar para convertir el XML editado de nuevo en un SAMLRequest o SAMLResponse para hacer pruebas.
Cómo se codifican los mensajes SAML
| Binding | Mensajes habituales | Pasos de codificación | Dónde encontrarlo |
|---|---|---|---|
| HTTP-Redirect | AuthnRequest, LogoutRequest, LogoutResponse | XML → DEFLATE sin formato → base64 → codificación URL | Cadena de consulta: ?SAMLRequest=…&RelayState=…&SigAlg=…&Signature=… |
| HTTP-POST | Response (con aserción), a veces AuthnRequest | XML → base64 (los formularios POST lo codifican como URL) | Campo oculto de formulario SAMLResponse enviado a la URL ACS |
| HTTP-Artifact | Artifact, después ArtifactResolve / ArtifactResponse | Referencia corta al artefacto; el XML se obtiene por un canal secundario | Parámetro SAMLart |
Un mensaje POST decodificado empieza por <samlp:Response o <saml2p:Response; el base64 de un XML casi siempre empieza por PH (la codificación de <). Los mensajes Redirect comprimidos suelen empezar por fZ, nZ, jZ o similar.
Qué revisar cuando falla el inicio de sesión SAML
| Síntoma | Campo que revisar | Causa habitual |
|---|---|---|
| "Assertion expired" o "not yet valid" (aserción caducada o aún no válida) | Conditions NotBefore / NotOnOrAfter, SubjectConfirmationData NotOnOrAfter | Desfase del reloj del servidor; una respuesta antigua reutilizada; margen de desfase demasiado pequeño |
| "Audience invalid" (audiencia no válida) | AudienceRestriction / Audience | El entity ID del SP en la configuración del IdP difiere del entity ID propio del SP (barra final, http frente a https) |
| "Invalid destination" o "recipient" (destino o destinatario no válido) | Response Destination, SubjectConfirmationData Recipient | URL ACS configurada de forma distinta en el IdP y en el SP, o un proxy cambia el host |
| "InResponseTo mismatch" (InResponseTo no coincide) | InResponseTo | Inicio de sesión iniciado por el IdP enviado a un SP que espera uno iniciado por el SP, o el SP perdió el ID de la petición (se perdió la cookie de sesión) |
| "Signature invalid" (firma no válida) | Signature, huella del certificado | El IdP cambió su certificado de firma; el SP espera la aserción firmada pero solo lo está la respuesta (o al revés) |
| Usuario no encontrado o usuario incorrecto | NameID y formato, atributos | Formato de NameID incorrecto (persistent frente a email), nombres de atributos sin asignar |
Códigos de estado SAML habituales
urn:oasis:names:tc:SAML:2.0:status:Success: la petición se completó correctamente.…:status:Requester: la petición era incorrecta; mira el código de segundo nivel.…:status:Responder: el proveedor de identidad tuvo un problema.…:status:AuthnFailed: no se pudo autenticar al usuario.…:status:InvalidNameIDPolicy: el formato de NameID solicitado no está disponible.…:status:NoPassive: se solicitó IsPassive, pero el usuario debe interactuar para iniciar sesión.…:status:RequestDenied: el IdP se niega a responder, a menudo porque el usuario no está asignado a la aplicación.
Preguntas frecuentes
¿Cómo se codifica un SAMLResponse?
Con el binding HTTP-POST, el XML se codifica en base64 y se envía como el campo de formulario SAMLResponse, por lo que a menudo aparece codificado como URL en el cuerpo de la petición (%2B para +, %3D para =). Con el binding HTTP-Redirect, usado sobre todo para AuthnRequests y mensajes de cierre de sesión, el XML primero se comprime con DEFLATE sin formato y después se codifica en base64 y como URL en la cadena de consulta.
¿Por qué al decodificar en base64 un SAMLRequest salen caracteres ilegibles?
Porque los mensajes del binding Redirect se comprimen con DEFLATE antes de codificarse en base64. Hay que descomprimir los bytes decodificados (DEFLATE sin formato, RFC 1951) para obtener el XML. Esta herramienta lo detecta y los descomprime automáticamente.
¿Es seguro pegar aquí una respuesta SAML real?
La decodificación se ejecuta completamente en tu navegador y no se envía nada a ningún servidor. Aun así, trata las respuestas SAML como contraseñas: una aserción bearer que no ha caducado puede reutilizarse para iniciar sesión como ese usuario. Usa cuentas de prueba o mensajes caducados cuando los compartas con otras personas.
¿Esta herramienta verifica la firma XML?
No. Muestra qué está firmado (la Response, la Assertion o ambas), qué algoritmos se usan y la huella del certificado, para que puedas compararla con el certificado de los metadatos de tu IdP. La validación real de la firma debe hacerla la biblioteca SAML de tu proveedor de servicios con el certificado de confianza.
¿Qué significan NotBefore y NotOnOrAfter?
Definen el intervalo de tiempo en el que se puede aceptar la aserción. Conditions NotBefore/NotOnOrAfter limitan toda la aserción; SubjectConfirmationData NotOnOrAfter limita cuánto tiempo puede usarse la confirmación bearer, normalmente unos minutos. Si los relojes del IdP y del SP difieren, pueden fallar inicios de sesión válidos; la mayoría de las bibliotecas permiten un pequeño desfase de reloj, por ejemplo de 1 a 5 minutos.
¿Por qué mi aserción aparece como cifrada?
Algunos proveedores de identidad cifran la aserción con la clave pública del proveedor de servicios (EncryptedAssertion). Solo la clave privada del SP puede descifrarla, así que el decodificador puede mostrar la Response exterior y el estado, pero no el usuario ni los atributos que contiene.
¿Qué significa un estado InvalidNameIDPolicy o Requester?
El código de estado indica por qué falló el inicio de sesión. Requester significa que el error estaba en la petición del SP; un código de segundo nivel como InvalidNameIDPolicy significa que el formato de NameID solicitado no es compatible con esa aplicación, y AuthnFailed significa que el usuario no se autenticó. Corrige la petición del SP o la configuración del IdP y vuelve a intentarlo.
¿Se prueban todas las herramientas de FreeToolCabin para comprobar su calidad y precisión?
Sí. Cada herramienta del sitio pasa pruebas automáticas en navegadores reales para comprobar que el resultado es correcto y que no hay errores. Si encuentras un fallo o tienes una sugerencia, escríbenos a [email protected] y lo revisaremos.