Analizador SAML

SAML (Lenguaje de Marcado de Aserción de Seguridad) es un estándar basado en XML para intercambiar datos de autenticación y autorización entre proveedores de identidad (IdPs) y proveedores de servicio (SPs). Esta herramienta decodifica mensajes SAML desde URLs, maneja codificación Base64 y compresión DEFLATE, y formatea el XML para inspección.

Especificaciones

• OASIS SAML 2.0 Core
• OASIS SAML 2.0 Bindings
• SAML 2.0 Technical Overview

Casos de uso comunes

• Depurar flujos de autenticación de inicio de sesión único (SSO) empresarial
• Inspeccionar aserciones SAML de proveedores de identidad (Okta, Azure AD, ADFS)
• Solucionar problemas de integración SAML entre servicios
• Verificar atributos de aserción y valores de NameID
• Analizar parámetros de AuthnContext y sesión
• Auditar configuraciones SAML para revisión de seguridad

Funcionalidades

• Analizar mensajes AuthnRequest de SAML (SP a IdP)
• Decodificar SAML Response y aserciones (IdP a SP)
• Extraer SAMLRequest y SAMLResponse de parámetros de consulta URL
• Manejar codificación Base64 y compresión DEFLATE (enlace HTTP-Redirect)
• Formatear estructura XML con resaltado de sintaxis
• Mostrar resumen del mensaje (tipo, ID, IssueInstant, Destination, Status)
• Extraer Issuer, Subject/NameID y Conditions
• Mostrar atributos de aserción del AttributeStatement
• Indicador de presencia de firma

Ejemplos

https://sp.example.com/acs?SAMLResponse=PHNhbWxwOlJlc3BvbnNlLz4=

Consejos

• SAML usa dos enlaces principales: HTTP-Redirect (GET con deflate+base64) y HTTP-POST (POST con base64).
• El parámetro RelayState preserva la URL solicitada original a través del flujo SSO.
• Las aserciones SAML pueden estar firmadas, cifradas o ambas. Esta herramienta muestra el contenido decodificado.
• Verifique las condiciones NotBefore y NotOnOrAfter para validar la temporización de la aserción.

Comprender Analizador SAML

SAML (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). SAML 2.0, published by OASIS in 2005, remains the dominant protocol for enterprise Single Sign-On (SSO), enabling employees to authenticate once and access multiple applications.

A SAML SSO flow works as follows: a user attempts to access a service provider, the SP generates an AuthnRequest and redirects the browser to the IdP, the IdP authenticates the user and creates a SAML Response containing Assertions, and the browser POSTs this Response back to the SP. The assertion contains the user's identity (NameID), attributes (email, groups, roles), and conditions (validity window, audience restriction).

SAML messages are transported using bindings. The HTTP-Redirect binding encodes XML using DEFLATE compression and Base64 encoding in a URL query parameter. The HTTP-POST binding uses only Base64 and submits via an auto-submitting form. Debugging SAML requires decoding these layers to inspect the underlying XML.

SAML assertions can be signed (to prove they came from the IdP), encrypted (to prevent intermediaries from reading contents), or both. When troubleshooting SSO issues, the first step is always to decode the SAML Response and check the assertion's conditions, audience, timestamps, and attribute values.

SAML and OAuth 2.0/OpenID Connect serve different purposes. SAML is designed for enterprise SSO using XML-based assertions transported via browser redirects, and is most common in enterprise environments with identity providers like ADFS and Okta. OAuth 2.0 is an authorization framework for API access using JSON tokens, and OpenID Connect adds an authentication layer on top of OAuth using JWTs. OIDC is more common in modern web and mobile applications, while SAML remains dominant in corporate IT environments.

SAML messages often appear as unintelligible strings because they are encoded for transport. In the HTTP-POST binding, the XML is Base64-encoded. In the HTTP-Redirect binding, the XML is first DEFLATE-compressed, then Base64-encoded, then URL-encoded. Reading the original XML requires reversing these layers in the correct order. This tool handles all decoding steps automatically regardless of which binding was used.

When troubleshooting SAML errors, check several common causes: clock skew between the IdP and SP can cause assertion timestamps to fail validation; the Audience element must exactly match the SP's configured entity ID; assertions may have expired past their NotOnOrAfter time; the Destination attribute must match the SP's Assertion Consumer Service (ACS) URL; and the SP may not have the IdP's current signing certificate if it was recently rotated. The RelayState parameter also plays an important role in the SSO flow — it preserves the user's originally requested URL through the authentication redirect, so that after successful authentication, the SP can redirect back to the page the user initially tried to access.