Guide d'utilisation
Ce que c'est
Colle un SAMLResponse/SAMLRequest — l'URL complète d'un binding Redirect, la valeur en base64 d'un binding POST, ou le XML déjà décodé — et il est décodé et audité : signature, algorithmes, expiration, audience et le motif d'attaque classique XML Signature Wrapping (XSW). Rien ne sort du navigateur.
Vérifier la signature
Si tu colles le certificat de signature de l'IdP (en PEM, en base64 comme dans le metadata, ou le metadata entier), il vérifie chaque signature pour de vrai : que ce qui a été signé n'a pas changé (le digest) et que c'est la clé de ce certificat qui l'a signé. Jamais avec le certificat qui vient dans le message, dans KeyInfo : celui-là, c'est celui qui signe qui le met, et un attaquant met le sien. Une signature valide ne suffit pas : elle doit en plus couvrir l'assertion que lit ton application, et c'est la règle XSW qui le vérifie. Vérifié avec xmldsigjs, confronté à des réponses signées par de vrais IdP.
Ce que ceci NE fait PAS
Ne déchiffre pas les assertions chiffrées (il faudrait la clé privée du fournisseur de services, qui ne devrait être collée nulle part), ne vérifie pas la chaîne du certificat de l'IdP (en SAML on lui fait confiance parce qu'il est dans le metadata, pas à cause de qui l'a émis) et ne sait pas quel ID ton application lit vraiment : si ton code choisit l'assertion d'une autre façon, le XSW peut encore se glisser.
Qu'est-ce que XSW ?
XML Signature Wrapping : un attaquant injecte un nouvel élément (avec le même ID que l'original, ou un différent) pour que le code qui valide la signature regarde une chose et le code qui lit les données en regarde une autre. Cela continue de casser des implémentations SSO en production — PortSwigger l'a de nouveau documenté en 2025.
