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:

• diagnostic des anomalies des fournisseurs de service Shibboleth 3.x
• diagnostic des anomalies des fournisseurs d'identité Shibboleth 3.x

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.

Ce message d'erreur signifie que le fournisseur de service est incapable de produire une requête d'authentification a destination du fournisseur d'identité demandé, 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://pub.federation.renater.fr/metadata/test/preview/preview-all-renater-test-metadata.xml'

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

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

Ce message d'erreur indique que l'IdP a reçu une requête d'authentification indiquant un horaire incohérent, de son point de vue. Il est caractéristique d'une erreur de synchronisation d'horloge entre le SP et l'IdP, excédant une fenêtre de tolérance, fixée à 3 minutes dans le cas d'un IdP Shibboleth.

La solution consiste à vérifier l'horloge de l'IdP d'abord, celle du SP ensuite. Des deux cotés, il est nécessaire d'utiliser un mécanisme de synchronisation, tel NTP, assurant l'alignement sur un référentiel de temps partagé.

Ce message d'erreur produit par une application signale qu'elle n'a pas reçu du fournisseur d'identité un attribut obligatoire pour son fonctionnement. Ce problème peut avoir plusieurs origines:

1. l'IdP n'est pas capable de produire l'attribut, parce qu'il n'y a aucune règle de production pour celui-ci définie au niveau du mécanisme de résolution d'attribut (attribute resolver)
2. l'IdP est capable de produire cet attribut, mais pas de le transmettre, parce qu'aucune règle de filtrage (attribute filter) ne l'autorise pour ce SP spécifique
3. l'IdP est capable de produire cet attribut, de le transmettre, mais le SP ne le transmet pas à l'application, parce que sa valeur n'est pas valide (attribute filter, coté SP)
4. l'IdP est capable de produire cet attribut, de le transmettre, avec une valeur valide dans l'absolu, mais pas dans le cas particulier de l'utilisateur concerné, typiquement parce les valeurs définies dans l'annuaire sont manquantes ou invalides pour celui-ci

Le problème n°3 est relativement courant dans le cas d'attributs qualifiés (scoped, en anglais), et notamment l'identifiant institutionnel eduPersonPrincipalName, dans lesquels la partie droite (scope, en anglais) doit faire partie des valeurs déclarées comme légitime par l'IdP qui les produit dans les métadonnées de la fédération:

• prenom.nom@domaine.tld est une valeur valide pour une adresse e-mail, venant de n'importe quel IdP, car il ne s'agit pas d'un attribut contraint, mais d'une simple chaine de caractères
• prenom.nom@domaine.tld n'est une valeur valide pour un attribut eduPersonPrincipalName que si l'IdP qui la produit se déclare légitime lui-même pour domaine.tld dans les métadonnées de la fédération, car il s'agit d'un attribut contraint

Pour plus de détails, voire cette documentation.

Du point de vue de l'application, ces différents cas sont indiscernables, elle ne reçoit aucune valeur. Seuls les journaux de l'IdP, d'une part, un outil d'analyse comme aacli, d'autre part, permettent d'identifier la cause exacte du problème