Freigeben über

Weitere Tipps zur Fehlerbehebung für Apps mit hoher Vertrauenswürdigkeit in SharePoint 2013

  • Artikel

Veröffentlichung des Originalartikels: 02.11.2012

Ich bin echt ein App-Typ und steh auf Entwicklung. Aber mal ehrlich, wenn ich mich noch ein weiteres Mal mit dem Problem „der Aussteller des Tokens ist kein vertrauenswürdiger Aussteller“ für meine neuen SharePoint-Apps befassen muss, werde ich mich vor meinem Computer heiser schreien. Damit Hals, Stimme (und die geistige Gesundheit) meiner Mitstreiter geschont werden, möchte ich eine Liste mit Aktionen erstellen, die ich ausführe, sobald dieses Problem auftaucht. Wenn ich neue und spannende Möglichkeiten entdecke, diesen Fehler zu provozieren und zu lösen, werde ich diesen Beitrag hier aktualisieren und unten mit einem deutlichen „UPDATED!“ versehen.

Es ist wichtig zu verstehen, dass „App mit hoher Vertrauenswürdigkeit“ bedeutet, dass Sie NICHT ACS als vertrauenswürdigen Broker für Ihre SharePoint-App verwenden, sondern dass Sie das OAuth-Token erstellen und mit Ihrem eigenen Zertifikat signieren. Zu diesem gesamten Prozess liegt irgendwo eine Dokumentation vor, daher werde ich hier nicht näher darauf eingehen. Ich gehe in diesem Beitrag davon aus, dass Sie ihn gelesen und getestet haben und nun bereit sind, Ihrem Bildschirm den Kampf anzusagen. Dies vorausgeschickt, sind hier einige Situationen, in denen dieser Fehler aufgetreten ist:

  1. Hinzufügen zur SPTrustedRootAuthority-Liste: Wenn Sie OAuth-Token mit einem Zertifikat signieren, müssen Sie ein New-SPTrustedRootAuthority erstellen. Genau wie beim New-SPTrustedIdentityTokenIssuer in SharePoint 2010 müssen Sie das Zertifikat zum Signieren von Tokens hinzufügen sowie jedes andere Zertifikat in der Kette der SharePoint-Liste der vertrauenswürdigen Zertifizierungsstellen. Befolgen Sie die gleichen Schritte für diesen Vorgang, wie im folgenden Beitrag beschrieben: https://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx. Ignorieren Sie einfach alles über den Export des Zertifikats von ADFS. Ich gehe davon aus, dass Sie Ihr Zertifikat für Ihre Apps mit hoher Vertrauenswürdigkeit auf eine andere Art und Weise erstellt haben (öffentliche Root-CA wie GoDaddy, VeriSign usw., selbstsigniertes oder von der Domäne ausgegebenes Zertifikat).
  2. Client-ID verwendet nur Großbuchstaben: Wie ich bereits in einem anderen Beitrag erwähnt habe, dürfen Sie KEINE Großbuchstaben verwenden, wenn Sie beim Erstellen einer selbstgehosteten Lösung die Client-ID in der Datei „AppManifest.xml“ Ihrer Anwendung oder „web.config“ Ihrer Webanwendung bearbeiten. Weitere Informationen finden Sie hier: 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. Tokenaussteller ist nicht als vertrauenswürdiger Broker konfiguriert: Dieses Problem habe ich bereits in einem anderen Beitrag beschrieben: 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. Kurz gesagt, Sie dürfen beim Erstellen Ihrer New-SPTrustedSecurityTokenIssuer das Kennzeichen „-IsTrustBroker“ nicht vergessen.
  4. UPDATED!: Der Schlüssel „IssuerId“ fehlt in der Datei „web.config“ : Um in SharePoint 2013 die App-Funktion für vertrauenswürdige Broker zu verwenden, muss Ihre Anwendung die IssuerId des vertrauenswürdigen Brokers kennen, wenn sie das JWT-Token erstellt, das sie an SharePoint sendet. Hierfür sucht die Anwendung in der Datei „web.config“ nach einer App-Eigenschaft mit der Bezeichnung „IssuerId“. Diese befindet sich an derselben Position in Ihrer Datei „web.config“ wie „ClientId“, „ClientSecret“ usw. Und so sieht das Ganze aus: <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965"/>.
  5. UPDATED!: Verwenden von Office-Tools for Visual Studio 2012 RTM - Preview: Es gibt einen kleinen Fehler in RTM Preview, der in Preview 2 behoben wurde. Der Code, der dieses Autorisierungstoken an SharePoint sendet, sucht nicht nach dem IssuerId-Element in der Datei „web.config“ und sendet stattdessen einen anderen Wert. Was der Code sendet und warum, ist nicht wirklich wichtig. Es ist jedoch wichtig, dass Sie das Problem mit dieser Tools-Version umgehen, indem Sie stets den Wert „IssuerId“ für „SPTrustedSecurityTokenIssuer“ im Schlüssel „ClientId“ in Ihrer Datei „web.config“ verwenden. Sobald Sie über Preview 2 verfügen, installieren Sie es umgehend, und ändern Sie die ClientId in eine eindeutige GUID, die Sie erstellen und registrieren (mit „Register-SPAppPrincipal“, wie nachfolgend beschrieben). Die ClientIds sollten nicht alle übereinstimmen, da sie identifizieren, welche Anwendung das OAuth-Token signiert hat und weil sie für die gesamte SharePoint-Benutzeroberfläche verwendet werden. Bei der Fehlerbehebung oder Überprüfung ist es problematisch, wenn alle Apps denselben Wert verwenden.

Es gibt auch ein hiermit verwandtes Problem, auf das ich gerne hinweisen möchte: Stellen Sie sich vor, Sie „denken“, dass Sie diesen Fehler behoben haben, und dann erhalten Sie die Fehlermeldung „Zugriff verweigert“, wenn Sie versuchen, in Ihrer selbstgehosteten Anwendung Inhalt von einer SharePoint-Website abzurufen. Dies kann Folgendes bedeuten:

  1. Der ClientId-Wert in Ihrer Datei „AppManifest.xml“ für Ihre SharePoint-App stimmt nicht mit dem ClientId-Wert in der Datei „web.config“ für Ihre selbstgehostete App überein. Wir nehmen Verbesserungen an Ihren Visual Studio-Tools vor, die dieses Problem in den nächsten Versionen beheben werden.

Eine wirklich gute Frage ist, wie man solche Fehler findet, wenn Sie auftreten? Wenn das so einfach wäre, müsste ich mich wohl meinem Bildschirm gegenüber nicht so unfein benehmen. Hier sind jedoch die besten Datenquellen, die Sie verwenden können, wenn dieses Problem auftritt. Wenn ich noch weitere Lösungen finde, werde ich sie der Liste hinzufügen:

  1. ULS-Protokolle: Vor allem an Feiertagen öffne ich gerne die ULS-Protokolle und bewundere die schiere Menge an Daten. Ein echter Dauerbrenner. Okay, das war sarkastisch. Sie können jedoch wirklich zur Zentraladministration navigieren und die Überwachung für die Diagnoseprotokollierung konfigurieren. Erweitern Sie die SharePoint Foundation-Kategorie, und wählen Sie die folgenden Elemente aus: App Auth, Anwendungsauthentifizierung, Autorisierung der Authentifizierung und Forderungsauthentifizierung. Stellen Sie für diese Elemente die Protokollierungs- und Ablaufverfolgungsebenen auf „Ausführlich“ ein, und speichern Sie Ihre Änderungen. Starten Sie anschließend Ihre Anwendung erneut. Öffnen Sie eines der vielen Ansichtstools für ULS-Protokolle, um zu beobachten, wie Ihre Anforderung eingeht und verarbeitet wird. Auf diese Weise können Sie eventuell Hinweise auf Ihre App-Authentifizierungsprobleme sammeln.
  2. Fiddler: Fiddler ist sehr beliebt und ebenfalls hilfreich in diesen Situationen. Am häufigsten tritt der Fehler „401 - Nicht autorisiert“ auf (z. B. wenn das Problem „der Aussteller des Tokens ist kein vertrauenswürdiger Aussteller“ zugrunde liegt). Wenn Sie sich den letzten Frame der Anforderung ansehen und auf die Registerkarte „Header“ im Frame für die Antworten klicken, sehen Sie ein WWW-Authentifizierungscookie, das in etwa wie folgt aussieht: 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>" . Was können wir dem entnehmen? Bei genauerer Betrachtung weiß ich, dass erwartet wird, dass mein ClientId-Wert „e9134021-0180-4b05-9e7e-0a9e5a524965“ lautet und mein realm-Wert „8a96481b-6c65-4e78-b2ef-a446adb79b59“. Der ClientId-Wert kann ganz einfach überprüft werden, und zwar in der Datei „AppManifest.xml“ und in der „web.config“ für meine selbstgehostete App. Es ist sehr unwahrscheinlich, dass Ihr realm-Wert falsch ist, aber Sie können dies überprüfen, indem Sie das folgende PowerShell-Cmdlet ausführen:

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

Dies gibt Ihren realm-Wert auf dem Bildschirm aus. Abschließend ist hier noch eine andere Sache, die Sie zur Überprüfung ausführen können. Stellen Sie sicher, dass Sie für die von Ihnen verwendete ClientId ein appPrincipal erstellt haben. Hier ist ein weiteres PowerShell-Cmdlet zur Überprüfung, wobei ich meinen obigen WWW-Authentifizierungsheader verwendet habe:

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

Wenn ein Fehler oder keine Ergebnisse ausgegeben werden, wissen Sie, dass kein gültiges SPAppPrincipal vorhanden ist. Verwenden Sie PowerShell, um eines zu erstellen, wie im nachfolgenden Beispiel:

$clientId = "some guid you create"
$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"

Hiermit ist meine Liste der Tipps zur Fehlerbehebung für Apps mit hoher Vertrauenswürdigkeit für heute erschöpft. Wenn mir noch mehr dazu einfällt, werde ich diesen Beitrag aktualisieren.

 

 

 

 

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter More TroubleShooting Tips for High Trust Apps on SharePoint 2013.