Dépannage

Ça ne marche pas ? Les erreurs SAML courantes

Le message d'erreur dépend de l'outil, mais les causes sont presque toujours les mêmes. Retrouvez la vôtre.

Astuce : collez la réponse SAML dans le décodeur ou utilisez le SP de test pour voir précisément quel contrôle échoue.

« Audience invalide » / « Audience restriction »Audience

Cause probable. L'assertion est destinée à un nom d'application différent de celui que l'application attend. L'écart peut tenir à un caractère : barre finale, http et https, URL et URN, majuscules.

Que faire ? Comparez l'Entity ID déclaré côté IdP avec celui de l'application (visible dans ses métadonnées) et rendez-les strictement identiques.
« ACS URL incorrecte » / « Recipient » / « Destination »Destination, Recipient

Cause probable. L'adresse où l'IdP envoie la réponse n'est pas exactement celle de l'application. Cas fréquent : un reverse proxy fait passer l'application de https à http en interne, ou ajoute un chemin.

Que faire ? Corrigez l'URL ACS déclarée côté IdP (copiez-la depuis les métadonnées de l'application). Vérifiez aussi la configuration d'URL publique de l'application derrière un proxy.
« Signature invalide » / « digest mismatch »Signature

Cause probable. Le contenu a changé après la signature, ou un composant a reformaté le XML en chemin (passerelle, antivirus web, copier-coller).

Que faire ? Récupérez la réponse brute (champ SAMLResponse) sans la retoucher. Vérifiez que l'encodage base64 n'est pas coupé par des retours à la ligne ou encodé deux fois.
« Certificat inconnu » / « signature ne correspond à aucun certificat »Signature

Cause probable. Le certificat configuré dans l'application n'est pas celui qui signe. Très souvent, l'IdP a renouvelé son certificat et l'application a gardé l'ancien.

Que faire ? Réimportez les métadonnées actuelles de l'IdP, ou copiez son certificat de signature en cours. Pour éviter la coupure, l'IdP devrait publier l'ancien et le nouveau pendant la transition.
« Assertion expirée » / « pas encore valide » (NotBefore, NotOnOrAfter)NotBefore, NotOnOrAfter

Cause probable. Les horloges du serveur de l'application et de l'IdP ne sont pas synchronisées, ou la durée de validité est très courte.

Que faire ? Synchronisez les serveurs (NTP). Prévoyez une tolérance de 2 à 5 minutes côté application. N'allongez la durée côté IdP qu'en dernier recours.
« InResponseTo inattendu » / « réponse non sollicitée »InResponseTo

Cause probable. L'application ne retrouve pas la demande dont la réponse parle : session perdue entre-temps (cookie bloqué, autre navigateur, autre onglet), plusieurs serveurs sans partage de session, ou connexion lancée depuis l'IdP alors que l'application l'interdit.

Que faire ? Relancez la connexion depuis l'application dans un seul onglet. Derrière un répartiteur de charge, partagez l'état de session. Pour l'IdP-initiated, autorisez-le explicitement si c'est voulu.
« NameID absent » ou format inattenduNameID

Cause probable. L'application attend une adresse e-mail et l'IdP envoie un identifiant opaque (ou l'inverse).

Que faire ? Alignez le format : emailAddress ou persistent des deux côtés, et vérifiez que l'IdP a bien la valeur correspondante pour l'utilisateur.
Les attributs (nom, groupes…) sont videsAttributs

Cause probable. L'IdP n'envoie pas l'attribut, ou sous un autre nom (mail, email ou un long nom de type URI).

Que faire ? Dans l'IdP, ajoutez l'attribut à la liste envoyée à cette application ; dans l'application, indiquez le nom exact, casse comprise.
Boucle de redirection infinie

Cause probable. L'application n'arrive pas à créer sa session après la réponse (cookie bloqué, en Secure sur du http interne, ou ACS qui redirige elle-même vers la connexion).

Que faire ? Vérifiez les cookies de session (domaine, Secure, SameSite) et que l'ACS n'est pas protégée par la connexion qu'elle sert à faire.
L'utilisateur est authentifié mais « accès refusé »

Cause probable. Côté IdP, l'utilisateur n'est pas assigné à l'application, ou ses groupes ne correspondent pas aux règles de l'application.

Que faire ? Assignez l'utilisateur (ou son groupe) à l'application dans l'IdP, puis contrôlez les attributs de groupe envoyés.
« Assertion chiffrée » non lisibleAssertion chiffrée

Cause probable. L'IdP chiffre les assertions mais l'application n'a pas la clé de déchiffrement, ou le mauvais certificat de chiffrement a été fourni à l'IdP.

Que faire ? Fournissez à l'IdP le certificat de chiffrement de l'application (use="encryption") et gardez la clé privée correspondante. ID-Kit ne déchiffre pas encore : désactivez le chiffrement pour le test.
« Impossible de décoder SAMLRequest »Redirect

Cause probable. Avec le binding Redirect, la demande est compressée (deflate) avant le base64. Un outil qui décode seulement le base64 voit des caractères illisibles.

Que faire ? Utilisez le décodeur ID-Kit, qui gère la compression, ou vérifiez que l'URL n'a pas été tronquée.
« Statut : RequestDenied » / « AuthnFailed »Statut

Cause probable. L'IdP refuse : application inconnue (Entity ID non déclaré), ACS non déclarée, utilisateur inconnu, ou authentification échouée.

Que faire ? Lisez le StatusMessage et le journal de l'IdP. Vérifiez que l'application y est déclarée avec le bon Entity ID et la bonne ACS.

Envie de voir ça en vrai ? ID-Kit joue le rôle qui vous manque et vous montre chaque étape.

Ouvrir mon espaceDécoder une réponse SAML