Analyseur SAML

SAML (Security Assertion Markup Language) est un standard basé sur XML pour l'échange de données d'authentification et d'autorisation entre les fournisseurs d'identité (IdP) et les fournisseurs de services (SP). Cet outil décode les messages SAML depuis les URL, gère l'encodage Base64 et DEFLATE, et affiche le XML formaté pour inspection.

Specifications

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

Cas d'utilisation courants

• Déboguer les flux d'authentification SSO (Single Sign-On) en entreprise
• Inspecter les assertions SAML des fournisseurs d'identité (Okta, Azure AD, ADFS)
• Dépanner l'intégration SAML entre services
• Vérifier les attributs d'assertion et les valeurs NameID
• Analyser le contexte d'authentification et les paramètres de session
• Auditer les configurations SAML pour la revue de sécurité

Fonctionnalites

• Analyser les messages AuthnRequest SAML (SP vers IdP)
• Décoder les réponses et assertions SAML (IdP vers SP)
• Extraire SAMLRequest et SAMLResponse des paramètres de requête URL
• Gérer l'encodage Base64 et la compression DEFLATE (binding HTTP-Redirect)
• Afficher la structure XML formatée avec coloration syntaxique
• Afficher l'aperçu du message (type, ID, IssueInstant, Destination, Statut)
• Extraire l'émetteur, le sujet/NameID et les conditions
• Afficher les attributs d'assertion depuis l'AttributeStatement
• Indicateur de présence de signature

Exemples

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

Conseils

• SAML utilise deux bindings principaux : HTTP-Redirect (GET avec deflate+base64) et HTTP-POST (POST avec base64).
• Le paramètre RelayState préserve l'URL demandée initialement tout au long du flux SSO.
• Les assertions SAML peuvent être signées, chiffrées ou les deux. Cet outil affiche le contenu décodé.
• Vérifiez les conditions NotBefore et NotOnOrAfter pour valider le timing de l'assertion.

Comprendre Analyseur 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.