Decodificador de SAML

La herramienta es compatible con Respuestas y Aserciones SAML en XML codificado en Base64, comúnmente encontradas en redirecciones SAML y enlaces POST. También detecta y descomprime automáticamente solicitudes SAML comprimidas con deflate.

Sí. Todo el procesamiento se realiza completamente en tu navegador. Tus tokens SAML nunca se envían a ningún servidor. Ningún dato sale de tu dispositivo.

Las solicitudes SAML enviadas mediante redirección HTTP suelen comprimirse con deflate antes de la codificación Base64 para reducir la longitud de la URL. Esta herramienta detecta y descomprime automáticamente dichos datos.

Una solicitud es un samlp:AuthnRequest que el proveedor de servicios envía para pedirle al proveedor de identidades que autentique a un usuario; una respuesta es el samlp:Response que regresa, transportando la saml:Assertion con la declaración de autenticación y los atributos. Ambas viajan codificadas en URL (Redirect binding) o dentro de un formulario HTML POST (POST binding). Esta herramienta decodifica en ambas direcciones.

Una cadena opaca que el SP adjunta a la solicitud y que el IdP debe devolver sin cambios junto con la respuesta - normalmente es la URL a la que redirigir después del inicio de sesión. La especificación de bindings de SAML recomienda mantenerla por debajo de 80 bytes, y no tiene ningún significado para el IdP. Cuando el SSO aterriza en la página equivocada, un RelayState perdido o corrupto es el principal sospechoso.

En el binding HTTP-Redirect, el XML se comprime con raw-Deflate, luego se codifica en Base64 y después se codifica en URL - los tres pasos que exige la especificación. Dale a esta herramienta el valor codificado en URL: si se expande a marcado que comienza con <, estaba comprimido; si ya comienza con <?xml o <saml, no lo estaba. Los mensajes del binding POST son Base64 sin Deflate.

Desfase de reloj - la validación de la firma falla cuando los relojes del SP y del IdP difieren más del margen permitido; discrepancia de audience - el audienceRestriction de la aserción no contiene el entity ID del SP; y respuestas expiradas (NotOnOrAfter). También son comunes un RelayState faltante y aserciones sin firma cuando el SP las exige. Los campos decodificados que muestra esta herramienta te permiten verificar cada uno de estos puntos directamente.

Sí - decodificar no es verificar. El XML de la aserción es legible por cualquiera; la firma que contiene cubre la integridad, no la confidencialidad. Lo que no puedes hacer sin el certificado público del IdP es demostrar que la aserción es auténtica y no ha sido modificada. Trata cualquier contenido decodificado con cuidado: las aserciones suelen contener direcciones de correo electrónico, grupos y permisos.