Décodeur de réponses et requêtes SAML

Comment décoder un message SAML

1. Collez ce que vous avez. Tout ceci fonctionne :
   • la valeur SAMLResponse ou SAMLRequest seule, encodée en URL ou non
   • SAMLRequest=… avec ou sans RelayState, SigAlg et Signature
   • une URL Redirect complète copiée depuis la barre d’adresse
   • le formulaire HTML à envoi automatique avec le champ caché SAMLResponse
   • du XML brut
2. Le décodeur détecte le binding : du Base64 simple signifie HTTP-POST, des données compressées en deflate signifient HTTP-Redirect.
3. Lisez d’abord le résumé, puis le XML formaté en dessous. Le XML est affiché comme du texte et n’est jamais interprété.

Le sens Encoder fait l’inverse : collez un AuthnRequest et obtenez une valeur Redirect, un paramètre SAMLRequest= ou une URL complète construite à partir de l’attribut Destination. C’est pratique pour rejouer une requête pendant les tests d’un fournisseur de services.

Binding Redirect ou binding POST

Le binding Redirect compresse parce que les URL ont des limites de longueur en pratique. Dans l’exemple utilisé sur cette page, un AuthnRequest de 464 caractères se compresse en 273 octets et voyage sous forme de 364 caractères Base64. Les réponses transportent des signatures et des certificats : elles sont trop grosses pour une URL et passent par POST. Le décodeur accepte aussi les données avec en-tête zlib, que certains fournisseurs de services envoient en Redirect à la place du raw deflate.

Que vérifier quand le SSO échoue

Le résumé met en avant les champs responsables de la plupart des échecs de connexion :

• Status : tout ce qui n’est pas urn:oasis:names:tc:SAML:2.0:status:Success. Un sous-code comme AuthnFailed, InvalidNameIDPolicy ou RequestDenied indique la raison, et StatusMessage ajoute souvent des détails.
• Destination et URL ACS : doivent correspondre exactement au point de terminaison configuré chez le fournisseur de services, https et barre oblique finale compris.
• Audience : doit être égale à l’entity ID du SP. Un écart ici est une erreur de configuration fréquente après le renommage d’une application.
• Conditions : NotBefore et NotOnOrAfter sont comparés à votre horloge. « Expirées » ou « pas encore valides » sur une connexion toute fraîche indique un décalage d’horloge entre l’IdP et le SP.
• InResponseTo : doit être égal à l’ID de l’AuthnRequest. Un écart évoque une réponse périmée ou rejouée. L’attribut est absent des connexions initiées par l’IdP, que certains fournisseurs de services refusent.
• NameID et Format : l’identifiant que le SP va comparer à ses utilisateurs, par exemple emailAddress ou persistent.
• Attributs : chaque attribut avec toutes ses valeurs, pour confirmer que l’IdP envoie bien les groupes ou l’e-mail que le SP attend.

Décoder du 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()

Le -15 indique à zlib d’attendre du raw deflate sans en-tête. N’appelez unquote que sur des valeurs copiées depuis une URL : une valeur issue d’un formulaire POST est déjà du Base64 simple, et la décoder comme une URL peut transformer + en espace. Plus de détails dans Base64 en Python ; la compression est expliquée sur la page raw deflate et zlib.

Confidentialité des assertions SAML

Une assertion contient des noms, des adresses e-mail, des appartenances à des groupes et parfois d’autres données personnelles, et une assertion valide non expirée peut servir de jeton de connexion. Cette page la décode localement et ne peut l’envoyer nulle part. Masquez tout de même les assertions avant de les coller dans un ticket ou une discussion, et traitez une réponse capturée comme un cookie de session tant que son NotOnOrAfter n’est pas dépassé.

FAQ