Conseils supplémentaires pour dépanner les applications à haut niveau de fiabilité sur SharePoint 2013

  • Article

Article d’origine publié le vendredi 2 novembre 2012

Bonjour, je suis un expert en applications, j’aime faire du développement, mais honnêtement, il peut m’arriver de hurler jusqu’à l’extinction de voix si je dois suivre une fois de plus un problème du genre « L’émetteur du jeton n’est pas un émetteur approuvé » avec mes nouvelles applications SharePoint. Pour vous aider à sauver votre propre voix (et votre santé mentale) je vais répertorier ici les éléments que je vérifie lorsque ce problème se pose. Au fur et à mesure que je découvrirai de nouvelles méthodes intéressantes pour appeler cette erreur et de la résoudre, je mettrai à jour ce billet en indiquant : « MIS À JOUR ! ».

Il est important de se rappeler que lorsque je dis « application à haut niveau de fiabilité », cela signifie que vous n’utilisez PAS les services de contrôle d’accès (ACS) comme broker d’approbation pour votre application SharePoint ; à la place vous créez le jeton OAuth et le signez avec votre propre certificat. Je sais que l’ensemble de ce processus est documenté quelque part, je ne vais donc pas essayer de le décrire de nouveau ici. Je vais supposer que vous l’avez lu, essayé et que vous êtes maintenant prêt à narguer votre moniteur. Cela étant dit, voici certaines des façons dont j’ai vu cette erreur se produire :

  1. Ajout à la liste SPTrustedRootAuthority : lorsque vous utilisez un certificat pour signer vos jetons OAuth, vous devez créer un New-SPTrustedRootAuthority. Comme pour New-SPTrustedIdentityTokenIssuer dans SharePoint 2010, vous devez ajouter le certificat de signature de jetons et tous les certificats de la chaîne à la liste des autorités approuvées de SharePoint. Vous pouvez suivre les mêmes étapes pour ce processus que celles décrites dans ce billet : https://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx. Vous pouvez ignorer la partie traitant de l’exportation de certificat depuis l’autorité de certification publique racine ADFS (je suppose que vous avez créé votre certificat pour vos applications à haut niveau de fiabilité via un autre moyen) comme GoDaddy, VeriSign, etc., un certificat auto-signé ou un certificat émis par un domaine.
  2. L’ID client utilise tous les caractères majuscules : comme décrit dans un autre billet, assurez-vous de ne PAS utiliser de lettres majuscules lorsque vous entrez l’ID client dans le fichier AppManifest.xml de votre application ou dans le fichier web.config de votre application web, si vous créez une solution auto-hébergée. Pour plus d’informations, voir : https://blogs.technet.com/b/speschka/archive/2012/07/28/an-important-tip-about-client-id-values-for-s2s-apps-in-sharepoint-2013.aspx.
  3. L’émetteur de jeton n’est pas configuré comme broker d’approbation : j’ai également décrit ce problème dans un autre billet ici :https://blogs.technet.com/b/speschka/archive/2012/09/27/another-apps-for-sharepoint-tip-with-the-error-quot-the-issuer-of-the-token-is-not-a-trusted-issuer-quot.aspx. L’objectif, ici, est de s’assurer que, lorsque vous créez votre New-SPTrustedSecurityTokenIssuer, vous incluez la balise -IsTrustBroker.
  4. MIS À JOUR ! : Clé IssuerId manquante dans le fichier web.config : pour utiliser la fonctionnalité de broker d’approbation des applications dans SharePoint 2013, votre application doit connaître le IssuerId du broker d’approbation lorsqu’elle crée le jeton JWT et l’envoie à SharePoint. Pour le connaître elle recherche dans le fichier web.config une propriété d’application appelée IssuerId. Elle se trouve au même endroit dans le fichier web.config de votre application que ClientId, ClientSecret, etc. Elle ressemble à ceci :<add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965"/>.
  5. MIS À JOUR ! : Utilisation de la version d’évaluation RTM des Outils Office pour Visual Studio : il existe actuellement un petit bogue dans les octets de la version d’évaluation RTM, qui est corrigé dans la version d’évaluation 2 (ou Preview 2). Le code envoyant le jeton d’autorisation à SharePoint ne recherche pas l’élément IssuerId dans le fichier web.config : à la place il envoie une autre valeur. Ce qu’il envoie et la raison de cette erreur ne sont pas réellement importants ; ce qui EST important, c’est de savoir que la solution pour contourner ce problème avec cette version des outils est de toujours utiliser la valeur IssuerId pour SPTrustedSecurityTokenIssuer dans la clé ClientId de votre fichier web.config. Tandis que vous obtenez les octets de la version d’évaluation 2, installez-les immédiatement et modifiez ClientId sur un GUID unique que vous créez et enregistrez (avec Register-SPAppPrincipal, comme expliqué ci-dessous). Vous ne voulez pas que tous les ClientId soient identiques car ils identifient l’application qui a signé le jeton OAuth et qui est utilisée dans l’ensemble de l’IU de SharePoint. Si jamais vous devez effectuer un dépannage ou une audit, le fait que toutes les applications utilisent la même valeur poserait.

Maintenant, il existe également un problème connexe qu’il faut connaître : supposez que vous « pensez » avoir passé cette erreur, mais qu’ensuite vous obtenez une erreur « Accès refusé » lorsque vous tentez de récupérer le contenu d’un site SharePoint dans votre application auto-hébergée. Cela signifie donc que :

  1. La valeur ClientId dans votre fichier AppManifest.xml pour votre application SharePoint ne correspond pas à la valeur ClientId dans le fichier web.config pour votre application auto-hébergée. Nous apportons des améliorations aux outils Visual Studio. Elles doivent désormais atténuer ce problème.

Maintenant se pose une question tout aussi importante : comment suivre ce genre d’événements lorsqu’ils se produisent ? Si c’était facile je n’en viendrais pas à m’énerver. Mais voici les meilleures sources de données que j’ai trouvées pour le moment lorsque ce problème se produit. Encore une fois, j’ajouterai de nouveaux éléments au fur et à mesure que je les trouve :

  1. Journaux ULS : ceci me plaira toujours, en particulier pendant les fêtes ; j’aime ouvrir les journaux ULS et simplement admirer le l’important volume de données. Bon, c’était sarcastique. Mais ce que vous pouvez réellement faire est d’accéder à Administration centrale, Surveillance, Configurer la journalisation des diagnostics. Développez la catégorie SharePoint Foundation et sélectionnez les éléments suivants : Authentification d’application, Autorisation d’authentification et Authentification par revendications. Définissez le niveau de journalisation et de suivi de ces éléments sur Détaillé, enregistrez vos modifications, puis tentez de redémarrer votre application. Utilisez l’un des nombreux outils d’affichage de journal ULS pour consulter l’arrivée et le traitement de votre requête. C’est un bon moyen de rassembler des indices sur vos problèmes d’authentification d’application.
  2. Fiddler : un de mes outils favoris. Fiddler est très utile pour ce genre de situations. Ce que vous verrez le plus souvent est une erreur « 401 Non autorisé » (comme à chaque fois que le problème sous-jacent est « L’émetteur du jeton n’est pas un émetteur approuvé »). Si vous regardez le dernier cadre dans la requête et cliquez sur l’onglet En-têtes dans le cadre Réponse, vous verrez un cookie WWW-Authenticate qui ressemble à ceci : Bearer realm="8a96481b-6c65-4e78-b2ef-a446adb79b59",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="<e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59,00000003-0000-0ff1-ce00-000000000000@8a96481b-6c65-4e78-b2ef-a446adb79b59>" . Quelle est l’utilité de cela ?L’examen de ce cookie permet de savoir que, dans ce cas, la valeur ClientId doit être e9134021-0180-4b05-9e7e-0a9e5a524965 et que le domaine doit être 8a96481b-6c65-4e78-b2ef-a446adb79b59. La valeur ClientId est assez facile à vérifier, en recherchant dans le fichier AppManifest.xml et le fichier web.config pour mon application auto-hébergée. Il est très peu probable que votre domaine soit erroné, mais vous pouvez toujours vérifier en exécutant cette applet de commande PowerShell :

$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$realm

Cette applet affichera votre domaine. Enfin, il existe une autre solution pour contrôler la situation : assurez-vous dֹ’avoir créé un appPrincipal pour le ClientId que vous utilisez. Voici encore une applet de commande PowerShell que vous pouvez utiliser pour vérifier cela, en utilisant les informations d’en-tête WWW-Authenticate précédentes :

Get-SPAppPrincipal -NameIdentifier <e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59> -Site https://foo

Si vous obtenez une erreur ou aucun résultat alors vous savez que vous n’avez pas de SPAppPrincipal valide, et vous devez donc en créer un en utilisant PowerShell. Pour conclure, en voici un exemple :

$clientId = "un guid que vous créez"
$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$fullAppIdentifier = $clientId + <'@'> + $realm
$appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spsite.OpenWeb() -DisplayName "My Cool App"

Voila, avec ceci, ma liste de conseils pour dépanner les applications à haut niveau de fiabilité touche à sa fin. Si je trouve d’autres informations à communiquer, j’actualiserai ce billet.

 

 

 

 

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à l’adresse More TroubleShooting Tips for High Trust Apps on SharePoint 2013