Erstellen besonders vertrauenswürdiger Add-Ins für SharePoint

Eine besonders vertrauenswürdiges Add-In ist ein vom Anbieter gehostetes SharePoint-Add-In, das digitale Zertifikate verwendet, um eine Vertrauensstellung zwischen der Remote-Webanwendung und SharePoint zu schaffen. "Besonders vertrauenswürdig" ist nicht identisch mit "volle Vertrauenswürdigkeit". Ein besonders vertrauenswürdiges Add-In muss weiterhin Add-In-Berechtigungen anfordern. Das Add-In wird als "besonders vertrauenswürdig" betrachtet, da ihm das Vertrauen entgegengebracht wird, alle Benutzeridentitäten zu verwenden, die das Add-In benötigt, da das Add-In verantwortlich für das Erstellen des Benutzerbereichs des Zugriffstokens ist, das es an SharePoint weitergibt.

Ein SharePoint-Add-In hoher Vertrauenswürdigkeit ist in erster Linie für die Verwendung in einer lokalen Umgebung gedacht. Das Add-In mit hoher Vertrauenswürdigkeit kann nicht auf Microsoft SharePoint Online installiert werden, und die Remotekomponenten werden in der Regel auch lokal installiert innerhalb der Unternehmensfirewall installiert. Daher werden die Instanzen der SharePoint-Add-In an die Besonderheiten jedes Unternehmens angepasst.

Ein Add-In mit hoher Vertrauenswürdigkeit verwendet ein Zertifikat und kein Kontexttoken, um eine Vertrauensstellung zu schaffen. (Ein vom Anbieter gehostetes Add-In, das für die Verwendung von Microsoft Azure Access Control Service (ACS) als Vertrauensbroker entwickelt wurde, muss so geändert werden, dass er als besonders vertrauenswürdige App funktioniert.) Besonders vertrauenswürdige Add-Ins erfordern einige Konfigurationen in der SharePoint-Farm und auf dem Server, auf dem die Remotewebanwendung gehostet wird.

In SharePoint stellt der Server-zu-Server-Sicherheitstokendienst (Security Token Service, STS) Zugriffstoken für die Server-zu-Server-Authentifizierung bereit. Der Server-zu-Server-STS ermöglicht es temporären Zugriffstoken, auf andere Anwendungsdienste, wie z. B. Exchange, Lync und Add-Ins für SharePoint, zugreifen. Sie richten eine Vertrauensstellung zwischen den Anwendungsdiensten (z. B. die Einrichtung einer Vertrauensstellung zwischen SharePoint und einem Remote-Add-In) mithilfe von Windows PowerShell-Cmdlets und einem Zertifikat ein.

Hinweis

Der Server-zu-Server-STS ist nicht für die Benutzerauthentifizierung vorgesehen. Daher wird der Server-zu-Server-Sicherheitstokendienst weder auf der Benutzeranmeldeseite noch im Abschnitt Authentifizierungsanbieter der Zentraladministration oder in der Personenauswahl in SharePoint angezeigt.

In diesem Artikel wird beschrieben, wie Sie ein besonders vertrauenswürdiges Add-In erstellen. Außerdem werden Ausweisungen bereitgestellt, wie Sie das Add-In so einrichten, dass es in Visual Studio durch Auswahl der Taste F5 ausgeführt werden kann. Sie lernen Folgendes:

  • Konfigurieren eines Add-Ins für die Verwendung als besonders vertrauenswürdiges Add-In.
  • Konfigurieren von SharePoint für die Verwendung von besonders vertrauenswürdigen Apps.
  • Erstellen einer einfachen besonders vertrauenswürdigen App.

Test-, Staging- oder Produktionsumgebung werden anders konfiguriert. Eine Beschreibung finden Sie im Thema Packen und Veröffentlichen besonders vertrauenswürdiger Add-Ins für SharePoint.

Voraussetzungen

Um die Verfahren in diesem Artikel ausführen zu können, benötigen Sie Folgendes:

Abrufen eines Zertifikat oder Erstellen eines öffentlichen und privaten Testzertifikats

Sie benötigen ein digitales X.509-Zertifikat für die Remote-Webanwendung des Add-Ins mit hoher Vertrauenswürdigkeit. Um das SharePoint-Add-In vollständig zu testen, benötigen Sie ein von der Domäne ausgegebenes Zertifikat oder ein kommerzielles Zertifikat, das von einer Zertifizierungsstelle ausgestellt wurde. In der Anfangsphase des Debuggings können Sie jedoch ein selbstsigniertes Zertifikat verwenden.

Im folgende Verfahren wird beschrieben, wie Sie mit IIS ein Testzertifikat erstellen und exportieren. Im Abschnitt Durchführen des Debugging für ein von einer Domäne ausgestelltes oder kommerzielles Zertifikat erfahren Sie, wie Sie das selbstsignierte Zertifikat durch ein von einer Domäne ausgestelltes oder kommerzielles Zertifikat ersetzen.

Sie können auch das MakeCert-Testprogramm verwenden, um ein X.509-Zertifikat zu erstellen. Weitere Informationen zur Verwendung von MakeCert finden Sie unter Signieren und Überprüfen von Code mit Authenticode.

Sie werden zuerst eine PFX-Zertifikatstestdatei und dann eine entsprechende CER-Testdatei erstellen. Das PFX-Zertifikat enthält den privaten Schlüssel, der von der Remote-Webanwendung verwendet wird, um die Kommunikation mit SharePoint zu signieren. Die CER-Datei enthält den öffentlichen Schlüssel, den SharePoint verwendet, um die Nachrichten zu entschlüsseln, und sicherzustellen, dass diese von der Remote-Webanwendung stammen und dass die Remote-Webanwendung ein Zugriffstoken von einem Token-Herausgeber besitzt, dem SharePoint vertraut. Weitere Informationen zu PFX- und CER-Dateien finden Sie unter Software Publisher Certificate.

So erstellen Sie eine selbstsignierte PFX-Zertifikatstestdatei

  1. Wenn Sie ein SharePoint Add-In mit hoher Vertrauenswürdigkeit in Visual Studio debuggen, wird die Remote-Webanwendung in IIS Express auf dem Computer gehostet, auf dem Visual Studio installiert ist. Daher verfügt der Computer der Remote-Webanwendung nicht über einen IIS-Manager, mit dem das Zertifikat erstellt werden kann. Aus diesem Grund verwenden Sie IIS auf dem SharePoint-Testserver, um das Zertifikat zu erstellen.

Wählen Sie im IIS-Manager in der Strukturansicht auf der linken Seite den Knoten ServerName aus.

  1. Wählen Sie das Symbol Serverzertifikate aus, wie in der folgenden Abbildung zu sehen ist.

Option „Serverzertifikate“ in IIS

  1. Wählen Sie in der Gruppe mit den Links auf der rechten Seite den Link Selbstsigniertes Zertifikat erstellen aus.

Link „Selbstsigniertes Zertifikat erstellen“

  1. Geben Sie für das Zertifikat den Namen HighTrustSampleCert ein, und wählen Sie dann OK aus.

  2. Klicken Sie mit der rechten Maustaste auf das Zertifikat, und wählen Sie dann Exportieren aus.

Exportieren eines Testzertifikats

  1. Erstellen Sie in Windows oder in einer Befehlszeile einen Ordner namens C:\Certs.

  2. Exportieren Sie im IIS-Manager die Datei nach „C:\Certs“, und weisen Sie ihr Kennwort zu. In diesem Beispiel lautet das Kennwort password.

  3. Wenn sich Ihre SharePoint-Testinstallation nicht auf demSelben Computer befindet, auf dem Visual Studio ausgeführt wird, erstellen Sie auf dem Visual Studio-Computer den Ordner C:\Certs, und verschieben Sie die Datei HighTrustSampleCert.pfx darauf. This is the computer where the remote web application runs when you are debugging in Visual Studio.

So erstellen Sie eine entsprechende CER-Datei

  1. Stellen Sie auf dem SharePoint-Server sicher, dass die Add-In-Pool-Identitäten für die folgenden IIS-Add-In-Pools über Leseberechtigungen für den Ordner „C:\Certs“ verfügen:
  • SecurityTokenServiceApplicationPool

  • Der Add-In-Pool, der der IIS-Website dient, die die übergeordnete SharePoint-Webanwendung für Ihre Test-SharePoint-Website hostet. Für die SharePoint - 80 IIS-Website wird der Pool als OServerPortalAppPool bezeichnet.

  1. Wählen Sie im IIS-Manager in der Strukturansicht auf der linken Seite den Knoten ServerName aus.

  2. Doppelklicken Sie auf Serverzertifikate.

  3. Doppelklicken Sie in der Ansicht Serverzertifikate auf HighTrustSampleCert, um die Zertifikatdetails anzuzeigen.

  4. Wählen Sie auf der Registerkarte Details die Option In Datei kopieren aus, um den Zertifikatexport-Assistenten zu starten. Wählen Sie anschließend Weiter aus.

  5. Verwenden Sie den Standardwert Nein, privaten Schlüssel nicht exportieren, und wählen Sie dann Weiter aus.

  6. Verwenden Sie die Standardwerte, und wählen Sie Weiter aus.

  7. Wählen Sie Durchsuchen aus, gehen Sie zu C:\Certs, geben Sie für das Zertifikat den Namen HighTrustSampleCert ein, und wählen Sie dann Speichern aus. Das Zertifikat wird als CER-Datei gespeichert.

  8. Wählen Sie Weiter aus.

  9. Wählen Sie Fertig stellen aus.

Konfigurieren von SharePoint für die Verwendung von Zertifikaten und Konfigurieren einer Vertrauensstellung für das Add-In

Das Windows PowerShell-Skript, das Sie in diesem Abschnitt erstellen, soll die Verwendung von F5 in Visual Studio unterstützen. Es wird keine ordnungsgemäße SharePoint-Staging- oder SharePoint-Produktionsinstallation konfiguriert. Anweisungen zum Konfigurieren einer SharePoint-Produktion zur Verwendung von Zertifikaten finden Sie unter Packen und Veröffentlichen besonders vertrauenswürdiger Add-Ins für SharePoint.

Wichtig

Stellen Sie sicher, dass Sie die Schritte unter Konfigurieren von Diensten in SharePoint für die Verwendung in Server-zu-Server-Add-Ins (dies wird als Voraussetzung für diesen Artikel aufgeführt) ordnungsgemäß ausgeführt haben. Wenn dies nicht der Fall ist, müssen Sie jetzt die Konfiguration vornehmen, um fortfahren zu können.

Konfigurieren von SharePoint

  1. Beginnen Sie in einem Text-Editor oder Windows PowerShell-Editor eine neue Datei, und fügen Sie die folgenden Zeilen hinzu, um ein Zertifikatsobjekt zu erstellen.
  $publicCertPath = "C:\Certs\HighTrustSampleCert.cer"
  $certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($publicCertPath)
  1. Fügen Sie die folgende Zeile hinzu, um sicherzustellen, dass SharePoint das Zertifikat als Stammzertifizierungsstelle behandelt.
  New-SPTrustedRootAuthority -Name "HighTrustSampleCert" -Certificate $certificate 
  1. Fügen Sie die folgende Zeile hinzu, um die ID des Autorisierungsbereichs abzurufen.
  $realm = Get-SPAuthenticationRealm
  1. Ihre Remote-Webanwendung verwendet ein Zugriffstoken, um Zugriff auf SharePoint-Daten zu erhalten. Das Zugriffstoken muss von einem Token-Herausgeber ausgegeben werden, dem SharePoint vertraut. Bei einem Add-In mit hoher Vertrauenswürdigkeit ist das Zertifikat der Token-Herausgeber. Fügen Sie die folgenden Zeilen hinzu, um eine Aussteller-ID im von SharePoint benötigten Format zu erstellen: _specific_issuer_GUID_@_realm_GUID_.
  $specificIssuerId = "11111111-1111-1111-1111-111111111111"
  $fullIssuerIdentifier = $specificIssuerId + '@' + $realm 

Hinweis

Der $specificIssuerId-Wert muss eine GUID sein, weil jedes Zertifikat in einer Produktionsumgebung über einen eindeutigen Herausgeber verfügen muss. In diesem Kontext, in dem Sie das gleiche Zertifikat verwenden, um alle Ihre Add-Ins mit hoher Vertrauenswürdigkeit zu debuggen, können Sie den Wert fest codieren. Wenn Sie aus irgendeinem Grund eine andere als die hier verwendeten GUID verwenden sollten, achten Sie darauf, dass alle Buchstaben in der GUID Kleinbuchstaben sind. Derzeit erfordert die SharePoint-Infrastruktur Kleinbuchstaben für die Zertifikatherausgeber-GUIDs.

  1. Fügen Sie die folgenden Zeilen hinzu, um das Zertifikat als vertrauenswürdigen Token-Herausgeber zu registrieren. Der -Name-Parameter muss eindeutig sein, sodass es in einer Produktionskonfiguration üblich ist, eine GUID als Teil des Namens (oder komplett als Namen) zu verwenden, aber in diesem Zusammenhang können Sie einen Anzeigenamen verwenden. Der -IsTrustBroker-Switch ist erforderlich, um sicherzustellen, dass Sie das gleiche Zertifikat für alle Add-Ins mit hoher Vertrauenswürdigkeit, die Sie entwickeln, verwenden können. Der iisreset-Befehl ist erforderlich, um Ihren Token-Herausgeber sofort zu registrieren. Ansonsten müssen Sie bis zu 24 Stunden warten, bis der neue Herausgeber registriert ist.
  New-SPTrustedSecurityTokenIssuer -Name "High Trust Sample Cert" -Certificate $certificate -RegisteredIssuerName $fullIssuerIdentifier -IsTrustBroker
  iisreset 
  1. SharePoint akzeptiert in der Regel keine selbstsignierten Zertifikaten. Wenn Sie für das Debuggen ein selbstsignierten Zertifikat verwenden, fügen Sie die folgenden Zeilen hinzu, um die SharePoint-Anforderung, das HTTPS verwendet werden muss, wenn eine Remote-Webanwendungen SharePoint aufruft, zu deaktivieren. Wenn Sie dies nicht tun, erhalten Sie eine 403 (Verboten)-Nachricht, wenn die Remote-Webanwendung SharePoint mit einem selbstsignierten Zertifikat aufruft. Sie können diesen Schritt in einem späteren Verfahren rückgängig machen. Durch das Deaktivieren der HTTPS-Anforderung werden Anfragen von der Remote-Webanwendung an SharePoint nicht verschlüsselt, aber das Zertifikat wird weiterhin als vertrauenswürdiger Herausgeber von Zugriffstoken verwendet, was auch die Hauptaufgabe des Zertifikats bei SharePoint-Add-Ins mit hoher Vertrauenswürdigkeit ist.
  $serviceConfig = Get-SPSecurityTokenServiceConfig
  $serviceConfig.AllowOAuthOverHttp = $true
  $serviceConfig.Update()
  1. Speichern Sie die Datei unter dem Namen HighTrustConfig-ForDebugOnly.ps1.

  2. Öffnen Sie die SharePoint-Verwaltungsshell als Administrator, und führen Sie die Datei mit der folgenden Zeile aus:

  ./HighTrustConfig-ForDebugOnly.ps1

Erstellen eines besonders vertrauenswürdigen SharePoint-Add-Ins

In diesem Abschnitt erstellen Sie ein besonders vertrauenswürdiges SharePoint-Add-In mit Visual Studio.

Hinweis

Wie im Abschnitt Voraussetzungen für die Erstellung von besonders vertrauenswürdigen Add-Ins angegeben, wird in diesem Artikel davon ausgegangen, dass Sie wissen, wie ein von einem Anbieter gehostetes SharePoint-Add-In erstellt wird. Weitere Informationen finden Sie unter Erste Schritte beim Erstellen von von einem Anbieter gehosteten SharePoint-Add-Ins.

So erstellen Sie ein besonders vertrauenswürdiges SharePoint-Add-In

  1. Klicken Sie in Visual Studio auf Datei>Neu>Projekt.

  2. Erweitern Sie im Assistenten Neues Projekt den Knoten Visual C# oder Visual Basic und anschließend den Knoten Office/SharePoint.

  3. Wählen Sie Add-Ins aus, und wählen Sie dann die Option zum Erstellen eines Projekts vom Typ Add-In für SharePoint aus.

  4. Nennen Sie das Projekt HighTrustSampleApp.

  5. Speichern Sie das Projekt an einem Speicherort Ihrer Wahl, und wählen Sie dann OK aus.

  6. Geben Sie die vollständige URL der SharePoint-Entwicklerwebsite an. Beispiel: http://TestServer/sites/devsite/

  7. Wählen Sie die Option Von Anbieter gehostet aus, und wählen Sie dann Weiter aus.

  8. Wenn Sie aufgefordert werden, die Art des Webprojekts anzugeben, wählen Sie ASP.NET Webformular-Anwendung für das fortlaufende Beispiel dieses Artikels aus, und wählen Sie dann Weiter aus.

  9. Die Seite Konfigurieren der Authentifizierungseinstellungen des Assistenten wird geöffnet. Die Werte, die Sie zu diesem Formular hinzufügen, werden automatisch zur Datei web.config hinzugefügt. Wählen Sie unter Wie soll Ihr Add-In authentifiziert werden?Ein Zertifikat verwenden aus.

  10. Klicken Sie auf Durchsuchen neben dem Feld Zertifikatspeicherort, und wechseln Sie zu dem Speicherort des selbstsignierten Zertifikats (PFX-Datei), das Sie erstellt haben (C:\Certs). Der Wert dieses Felds sollte den vollständigen Pfad C:\Certs\HighTrustSampleCert.pfx enthalten.

  11. Geben Sie im Feld Kennwort das Kennwort für das Zertifikat ein. In diesem Fall ist es Kennwort.

  12. Geben Sie die Aussteller-ID (11111111-1111-1111-1111-111111111111) in das Feld Aussteller-ID ein.

  13. Wählen Sie Fertig stellen aus. Ein Großteil der Konfiguration wird beim Öffnen der Lösung ausgeführt. In der Visual Studio-Projektmappe werden zwei Projekte erstellt, eines für die SharePoint-Add-In und das andere für die ASP.NET-Webanwendung.

So führen Sie das Add-In aus und debuggen es

  1. Die Office Developer Tools für Visual Studio generieren automatisch eine default.aspx- und eine default.aspx.cs-Datei, wenn das Projekt ASP.NET erstellt wird. Der generierte Code ruft den Titel des SharePoint-Hostwebs ab und druckt ihn auf die Standardseite der Remote-Webanwendung. Das genaue Markup und der Code in diesen Dateien variiert abhängig von der Version der Tools. Für dieses Thema verwenden Sie die generierte und unveränderte default.aspx- und default.aspx.cs-Datei.

  2. Um das SharePoint-Add-In und die zugehörige Remote-Webanwendung zu testen, wählen Sie F5 in Visual Studio. Die Webanwendung wird für IIS Express unter localhost bereitgestellt. Das SharePoint-Add-In wird auf der SharePoint-Zielwebseite installiert. Sie werden von SharePoint aufgefordert, die Berechtigungen erteilen, die das SharePoint-Add-In anfordert. Einige Versionen der Office Developer Tools für Visual Studio starten das Add-In sofort; andere öffnen die Seite Websiteinhalte Ihrer SharePoint-Zielwebsite, und das neue Add-In ist dort aufgelistet.

Starten Sie das Add-In, wenn es nicht automatisch gestartet wird. Die Remote-Webanwendung öffnet die in der AppManifest.xml-Datei als Startseite angegebene Seite "default.aspx". Das Add-In sollte der folgenden Abbildung ähneln.

Beispiel-App, die den Webtitel abruft

Durchführen des Debugging für ein von einer Domäne ausgestelltes oder kommerzielles Zertifikat

Das Windows PowerShell Skripts, das Sie zuvor erstellt haben, hat die übliche Anforderung von SharePoint deaktiviert, dass Remotewebanwendungen das HTTPS-Protokoll für den Zugriff auf SharePoint verwenden. Das Arbeiten mit deaktiviertem HTTPS kann dazu führen, dass Sie als Entwickler bestimmte Probleme beim Erstellen eines Add-Ins verpassen, die während einer Produktionsbereitstellung auftreten würden, bei der HTTPS erforderlich ist. Daher sollten Sie die abgeschlossenen Entwicklungs- und Debugphasen erst in Betracht ziehen, wenn Sie das Testzertifikat durch ein von der Domäne ausgestelltes oder kommerzielles Zertifikat ersetzt und dann das Add-In mit aktivierter HTTPS-Anforderung erneut getestet haben.

Wenn Sie das neue Zertifikat abgerufen haben, müssen Sie - sofern Sie dies noch nicht getan haben - ein Kennwort hinzuzufügen. In einer Produktionsumgebung würden Sie ein sicheres Kennwort verwenden, aber für das Debuggen eines SharePoint-Add-Ins können Sie alles verwenden. Sie benötigen das Zertifikat in zwei Formaten: Pfx und Cer. Wenn es nicht im Pfx-Format vorliegt, wenn Sie es erhalten, müssen Sie es möglicherweise mit einem Dienstprogramm in Pfx umwandeln. Wenn Sie eine Pfx-Datei besitzen, können Sie in IIS importieren und die Cer-Datei exportieren, wie im folgenden Verfahren beschrieben.

So importieren Sie das neue Zertifikat

  1. Legen Sie die PFX-Datei unter C:\Certs auf den SharePoint-Server. Für die Zwecke dieses Artikels wird davon ausgegangen, dass die Datei "MyCert.pfx" heißt. Ersetzen Sie "MyCert" in allen Anweisungen mit den tatsächlichen Namen des Zertifikats.

  2. Wählen Sie im IIS-Manager in der Strukturansicht auf der linken Seite den Knoten ServerName aus.

  3. Doppelklicken Sie auf das Symbol Serverzertifikate.

  4. Wählen Sie im Bereich Aktionen auf der rechten Seite Importieren aus.

  5. Verwenden Sie im Dialogfeld Zertifikat importieren die Schaltfläche „Durchsuchen“, um zu „C:\Certs\ MyCert.pfx“ zu navigieren, und geben Sie dann das Kennwort des Zertifikats ein.

  6. Achten Sie darauf, dass Dieses Zertifikat darf exportiert werden aktiviert ist, und wählen Sie dann OK aus.

  7. Klicken Sie in der Liste Serverzertifikate mit der rechten Maustaste auf das Zertifikat, und wählen Sie dann Exportieren aus.

  8. Exportieren Sie die Datei nach „C:\Certs“, und geben Sie das Kennwort an.

  9. Wenn sich Ihre SharePoint-Testinstallation nicht auf demselben Computer befindet, auf dem Visual Studio ausgeführt wird, verschieben Sie die Datei MyCert.pfx in den Ordner C:\Certs auf dem Visual Studio-Computer.

  10. Doppelklicken Sie in der Ansicht Serverzertifikate auf MyCert, um die Zertifikatdetails anzuzeigen.

  11. Wählen Sie auf der Registerkarte Details die Option In Datei kopieren aus, um den Zertifikatexport-Assistenten zu starten. Wählen Sie anschließend Weiter aus.

  12. Verwenden Sie den Standardwert Nein, privaten Schlüssel nicht exportieren, und wählen Sie dann Weiter aus.

  13. Verwenden Sie die Standardwerte. Wählen Sie Weiter aus.

  14. Wählen Sie Durchsuchen aus, gehen Sie zu C:\Certs, geben Sie für das Zertifikat den Namen MyCert ein, und wählen Sie dann Speichern aus. Das Zertifikat wird als CER-Datei gespeichert.

  15. Wählen Sie Weiter aus.

  16. Wählen Sie Fertig stellen aus.

So konfigurieren Sie SharePoint für die Verwendung des neuen Zertifikats

  1. Öffnen Sie die Datei „HighTrustConfig-ForDebugOnly.ps1“ zur Bearbeitung, und nehmen Sie die folgenden Änderungen vor:
  • Ersetzen Sie HighTrustSampleCert an beiden Stellen, an denen die Zeichenfolge angezeigt wird, durch MyCert.

  • Ersetzen Sie die spezifische Aussteller-ID 11111111-1111-1111-1111-111111111111, durch 22222222-2222-2222-2222-222222222222.

  • Ersetzen Sie „High Trust Sample Cert“ durch „My Cert“ oder einen anderen entsprechenden Anzeigenamen.

  • Ersetzen Sie in der Zeile $serviceConfig.AllowOAuthOverHttp = $truetrue durch false. Dadurch wird die Anforderung, dass HTTPS verwendet werden muss, wieder aktiviert.

  1. Speichern Sie die Datei.

  2. Öffnen Sie die SharePoint-Verwaltungsshell als Administrator, und führen Sie die Datei mit der folgenden Zeile aus:

  ./HighTrustConfig-ForDebugOnly.ps1

So konfigurieren Sie die Remote-Webanwendung um

  1. Öffnen Sie in Visual Studio die Datei „web.config“ des Webanwendungsprojekts, und nehmen Sie die folgenden Änderungen vor:
  • Ersetzen Sie im Schlüssel ClientSigningCertificatePathC:\Certs\HighTrustSampleCert.pfx durch C:\Certs\<MyCert>.pfx.

  • Ersetzen Sie den Wert des Schlüssels ClientSigningCertificatePassword durch das tatsächliche Kennwort des Zertifikats.

  • Ersetzen Sie den Wert des Schlüssels IssuerId durch 22222222-2222-2222-2222-222222222222.

  1. Wählen Sie F5, um das Add-In zu debuggen.

Lesen Sie nach Abschluss der Entwicklung Ihrer besonders vertrauenswürdigen App unter Packen und Veröffentlichen besonders vertrauenswürdiger Add-Ins für SharePoint die Anweisungen zum Verpacken und Veröffentlichen dieser Art von SharePoint-Add-In.

Welche Funktion haben die Dateien „TokenHelper“ und „SharePointContext“?

Die Office Developer Tools für Visual Studio enthalten die Datei TokenHelper.cs (oder .vb) in der Remote-Webanwendung. Einige Versionen der Tools enthalten auch eine Datei SharePointContext.cs (oder .vb).

Der Code in diese Dateien bewirkt Folgendes:

  • Konfigurieren von .NET zum Anerkennen von Zertifikaten beim Ausführen von Netzwerkaufrufen.

  • Abrufen eines Server-zu-Server-Zugriffstoken, das vom privaten Zertifikat der Remote-Webanwendung im Namen des angegebenen WindowsIdentity-Objekts signiert wurde und von SharePoint zum Einrichten der Vertrauensstellung verwendet wird.

  • Abrufen des SharePoint-Sicherheitstokendienst (STS)-Zertifikats.

  • In Anwendungen, die ein Autorisierungssystem mit niedriger anstelle von hoher Vertrauenswürdigkeit verwenden, verfügen diese Dateien über zusätzliche Aufgaben, beispielsweise die Behandlung von OAuth-Token für das unter OAuth-Ablauf mit Kontexttoken für Add-Ins in SharePoint beschriebene Szenario. Eine Beschreibung dieses Szenarios würde den Rahmen dieses Artikels jedoch sprengen.

In einem besonders vertrauenswürdigen Add-In gibt es kein Kontexttoken. Das Kontexttoken ist spezifisch für Konfigurationen, die authorizaton mit niedriger Vertrauensebene verwenden. Ein Zugriffstoken ist jedoch weiterhin erforderlich. Wenn Sie eine besonders vertrauenswürdige Konfiguration verwenden, muss Ihre Webanwendung den Benutzer genauso authentifizieren wie SharePoint (d. h., das Add-In ist für die Erstellung des Zugriffstokens einschließlich der IDs des Benutzers und des Identitätsanbieters verantwortlich).

Wenn Sie in Visual Studio mit F5 debuggen, verwenden die Microsoft Office Developer Tools für Visual Studio die Windows-Authentifizierung, und die beiden generierten Codedateien verwenden die Windows-Identität der Person, die das Add-In ausführt, um das Zugriffstoken zu erstellen. Wenn das Add-In veröffentlicht wurde, müssen Sie die Remote-Webanwendung im IIS-Manager auf die Verwendung der Windows-Authentifizierung konfigurieren, wenn Sie die beiden generierten Dateien ohne Änderung verwenden möchten.

Wenn das Add-In nicht die Windows-Authentifizierung in der Produktionsumgebung verwenden soll, müssen Sie die generierten Codedateien TokenHelper und/oder SharePointContext anpassen, damit ein anderes Authentifizierungssystem verwendet wird. Sie müssen diese Dateien auch anpassen, wenn die Remote-Webanwendung mit einer anderen Identität als der des Benutzers, der das SharePoint-Add-In ausgeführt, auf SharePoint zugreift. Wenn die Remote-Webanwendung PHP, node.js, Java oder eine andere Nicht-ASP.NET-Plattform ist, muss der Code die Benutzer-ID von dem verwendeten Authentifizierungssystem erhalten und die ID dann zu dem erstellen Zugriffstoken hinzufügen.

Siehe auch