Résolution des problèmes courants

Cette page énumère un certain nombre de messages d'erreurs courants d'un fournisseur de service ou d'identité Shibboleth, de façon à faciliter le diagnostic et la résolution des problèmes, dans le contexte spécifique du service de fédération d'identité assuré par RENATER.

Cette page n'a cependant pas vocation à se substituer à la documentation fournie par l'éditeur, plus générique et plus exhaustive, qui est accessible ici:

Fournisseur de service

A valid authentication statement was not found in the incoming message

Dans la majorité des cas, ce message d'erreur, visible à la fois de l'utilisateur final sur la page d'erreur du SP, et dans les logs de celui-ci, correspond à un problème de déchiffrement de la réponse de l'IdP. Soit le SP n'est pas capable gérer le chiffrement, soit il utilise un autre certificat que celui annoncé à l'IdP via les métadonnées de la fédération.

La confirmation de ce diagnostic est relativement simple, il suffit de comparer les métadonnées exportées automatiquement par le SP, le plus souvent à l'adresse http://mon.service.tld/Shiboleth.sso/Metadata, et qui reflètent sa configuration réelle, avec celles incluses dans les métadonnées de la fédération, qu'il faut récupérer à l'adresse de publication, et qui sont utilisées par les IdPs pour savoir comment communiquer avec lui.

Aux différences de formatage près (les espaces avant et après, et les retours chariots), la valeur en base 64 du certificat annoncé pour l'usage chiffrement doit être strictement le même pour que la communication fonctionne.

<md:KeyDescriptor use="encryption">
  <ds:KeyInfo>
    <ds:X509Data>
      <ds:X509Certificate>MIIC9DC...
...
...==</ds:X509Certificate>
    </ds:X509Data>
  </ds:KeyInfo>
</md:KeyDescriptor>

Si ce n'est pas le cas, il faut corriger la déclaration de l'entité sur le guichet de la fédération, et attendre les délais habituels de propagation des changements. Attention, seul le certificat courant est publié dans les métadonnées avec un usage chiffrement, le certificat temporaire n'est annoncé que pour un usage de signature.

Unknown or Unusable Identity Provider

Ce message d'erreur signifie que le fournisseur de service est incapable d'authentifier le message qu'il reçoit en provenance du fournisseur d'identité, parce qu'il est ne peut pas trouver les métadonnées correspondant à celui-ci. Le message complet précise d'ailleurs: opensaml::saml2md::MetadataException: Unable to locate metadata for identity provider (<identifiant SAML du fournisseur d'identité>)

Il peut y avoir plusieurs causes possibles:

  • il n'est pas configuré pour charger les métadonnées d'une fédération dans laquelle ce fournisseur d'identité est enregistré
  • il n'est pas capable de télécharger ces métadonnées, par exemple à cause d'un problème réseau
  • il n'est pas capable de valider la signature de ces métadonnées, par exemple à cause d'un problème d'utilisation du certificat correspondant

Pour identifier le problème exact, il faut vérifier quelles métadonnées sont censées être récupérées dans la configuration, puis vérifier qu'elles le sont effectivement, ce qui doit se traduire par la présence d'un fichier suffisamment récent (les métadonnées de nos fédérations expirent au bout de 9 jours) à l'emplacement correspondant à l'attribut backingFilePath. Ou alors regarder dans les logs, ou le problème est généralement signalé de manière explicite, par exemple:

ERROR XMLTooling.ParserPool : fatal error on line 0, column 0, message: unable to connect socket for URL 'https://metadata.federation.renater.fr/test/preview/preview-all-renater-test-metadata.xml'

Unable to resolve outbound message endpoint for relying party 'XXX'

Ce message d'erreur, qui apparait à la fois sur la page d'erreur affichée par le SP, et dans les traces du module apache (mod_shib), correspond à une erreur coté IdP, transmise ensuite dans sa réponse. Plus précisément, l'IdP est incapable de trouver une correspondance entre le point d'accès SAML indiqué par le SP pour lui répondre dans sa requête d'authentification, et les points d'accès SAML déclarés pour ce SP dans les métadonnées de la fédération. Parmi les causes d'incohérences les plus fréquentes:

  • le SP déclare un point d'accès SAML avec une URL HTTPS, mais demande à être contacté via HTTP, parce que l'utilisateur y accède via HTTP
  • le SP déclare un point d'accès SAML un avec nom d'hôte virtuel, mais demande à être contacté avec un autre nom, parce que plusieurs enregistrements DNS correspondent à son adresse
  • le SP ne déclare aucun point d'accès de type SLO (le guichet actuel ne le permet pas), mais envoie pourtant une requête de désauthentification à l'IdP

La cause exacte peut facilement être identifié en examinant le message d'erreur complet (dans les logs de l'IdP), qui indiquent ce qui est demandé exactement, avec ce qui est déclaré dans les métadonnées de la fédération. La correction consiste à aligner l'usage avec les déclarations, en modifiant l'un ou l'autre.

Exemple du message d'erreur complet

Profile Action PopulateBindingAndEndpointContexts: Unable to resolve outbound message endpoint for relying party 'XXX': EndpointCriterion [type={urn:oasis:names:tc:SAML:2.0:metadata}SingleLogoutService, trusted=false

Fournisseur d'identité

Unable to resolve outbound message endpoint for relying party 'XXX'

Voir l'explication pour le même message d'erreur dans la rubrique précédente.