Erstellen von SharePoint-Add-Ins, die sehr vertrauenswürdigen Autorisierung verwenden

  • Artikel

Ein besonders vertrauenswürdiges Add-In ist eine vom Anbieter gehostete SharePoint-Add-In, die in einer lokalen SharePoint-Farm installiert wird. Sie kann nicht in Microsoft SharePoint Online installiert werden oder über den Office Store vertrieben werden. Ein Add-In mit hoher Vertrauenswürdigkeit verwendet ein Zertifikat und kein Kontexttoken, um eine Vertrauensstellung zu schaffen.

Hinweis

In diesem Thema erfahren Sie mehr über das besonders vertrauenswürdige Autorisierungssystem für SharePoint-Add-Ins. Praktische Informationen zur Erstellung und Bereitstellung besonders vertrauenswürdiger Add-Ins finden Sie in den folgenden Themen:

In SharePoint stellt der Sicherheitstokendienst (Security Token Service, STS) Zugriffstoken für die Server-zu-Server-Authentifizierung bereit. Der STS aktiviert Zugriffstoken zum Zugreifen auf andere Anwendungsdienste wie Exchange, Lync und SharePoint-Add-Ins. Ein Farmadministrator richtet eine Vertrauensstellung zwischen SharePoint und der anderen Anwendung oder dem Add-In mithilfe von Windows PowerShell-Cmdlets und eines Zertifikats ein. Jedes verwendete Zertifikat muss von SharePoint mithilfe des New-SPTrustedRootAuthority Cmdlets als vertrauenswürdig eingestuft werden. Außerdem muss jedes Zertifikat als Tokenaussteller mithilfe des New-SPTrustedSecurityTokenIssuer-Cmdlets bei SharePoint registriert werden.

Hinweis

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

Zwei Arten von Tokenherausgebern

Die Remotewebanwendung eines Add-Ins mit hoher Vertrauenswürdigkeit ist an ein digitales Zertifikat gebunden. (Informationen dazu, wie dies funktioniert, finden Sie in den beiden Themen, zu denen zuvor eine Verknüpfung hergestellt wurde.) Das Zertifikat wird von der Remotewebanwendung zum Signieren der Zugriffstoken verwendet, die es in alle Anfragen an SharePoint einschließt. Die Webanwendung signiert das Token mit dem privaten Schlüssel des Zertifikats, und SharePoint überprüft dieses mit dem öffentlichen Schlüssel des Zertifikats. Das Zertifikat muss als vertrauenswürdiger Tokenaussteller registriert sein, bevor SharePoint den Token vertrauen kann, die es ausgibt.

Es gibt zwei Arten von Tokenherausgebern: Einige können nur Token für ein bestimmtes SharePoint-Add-In ausstellen; andere wiederum, die als Vertrauensstellungsbroker bezeichnet werden, können Token für mehrere SharePoint-Add-Ins ausstellen.

SharePoint-Farmadministratoren können ganz praktisch ermitteln, welche Art von Tokenherausgeber von den Optionen und Parameterwerten erstellt wird, die mit dem New-SPTrustedSecurityTokenIssuer-Cmdlet verwendet werden. Um einen Tokenherausgeber zu erstellen, der ein Vertrauensstellungsbroker ist, fügen Sie die -IsTrustBroker-Option zur Befehlszeile hinzu und verwenden einen eindeutigen Wert (nicht die Client-ID des Add-Ins) für den -Name-Parameter. Es folgt ein bearbeitetes Beispiel.

New-SPTrustedSecurityTokenIssuer -IsTrustBroker -RegisteredIssuerName "<full_token_issuer_name> " --other parameters omitted--

Zum Erstellen eines Tokenherausgebers, der kein Broker ist, wird die -IsTrustBroker-Option nicht verwendet. Es gibt einen weiteren Unterschied. Der Wert des -RegisteredIssuerName-Parameters weist immer die Form von zwei GUIDs auf, die durch das „@“-Zeichen getrennt sind; GUID@GUID. Die GUID auf der rechten Seite ist immer die ID des Authentifizierungsbereichs der SharePoint-Farm (oder des Websiteabonnements). Die GUID auf der linken Seite ist immer eine spezifische ID für einen Tokenherausgeber.

Es handelt sich um eine zufällige GUID, wenn ein Tokenherausgeber erstellt wird, der ein Vertrauensstellungsbroker ist. Wenn jedoch ein Tokenherausgeber erstellt wird, der kein Vertrauensstellungsbroker ist, muss die spezifische Herausgeber-GUID dieselbe GUID sein, die als Client-ID des SharePoint-Add-Ins verwendet wird. Dieser Parameter gibt einen Namen für den Herausgeber an. Er teilt SharePoint auch mit, welches SharePoint-Add-In das einzige ist, für das das Zertifikat Token ausstellen kann. Nachfolgend sehen Sie ein teilweises Beispiel:

$fullIssuerIdentifier = "<client_ID_of_SP_app> " + "@" + "<realm_GUID> "
New-SPTrustedSecurityTokenIssuer -RegisteredIssuerName $fullIssuerIdentifier --other parameters omitted--

Normalerweise wird das Cmdlet New-SPTrustedSecurityTokenIssuer in einem Skript verwendet, das andere Aufgaben durchführt, um SharePoint für besonders vertrauenswürdige Add-Ins zu konfigurieren. Weitere Informationen zu diesen Skripts und vollständige Beispiele für das Cmdlet New-SPTrustedSecurityTokenIssuer finden Sie unter Besonders vertrauenswürdige Konfigurationsskripts für SharePoint.

Entscheiden zwischen der Verwendung eines oder mehrerer Zertifikate für besonders vertrauenswürdige SharePoint-Add-Ins

SharePoint- und Netzwerkadministratoren können zwischen zwei grundlegenden Strategien wählen, wenn sie Zertifikate zur Verwendung durch besonders vertrauenswürdige SharePoint-Add-Ins abrufen und verwalten:

  • Verwenden des gleichen Zertifikats für mehrere SharePoint-Add-Ins

  • Verwenden eines separaten Zertifikats für jede SharePoint-Add-In

In diesem Abschnitt werden die Vor- und Nachteile der jeweiligen Strategie erläutert.

Der Vorteil der Verwendung desselben Zertifikats für mehrere SharePoint-Add-Ins besteht darin, dass ein Administrator weniger Zertifikate hat, denen er vertrauen und die er verwalten muss. Der Nachteil bei diesem Ansatz besteht darin, dass in einer Situation, in der Sie die Vertrauensstellung mit einem bestimmten SharePoint-Add-In auflösen möchten, der Administrator dies nur durch Entfernen des Zertifikats als Tokenherausgeber oder als Stammzertifizierungsstelle erzielen kann. Durch Entfernen des Zertifikats werden aber auch die Vertrauensstellungen mit allen anderen SharePoint-Add-Ins aufgehoben, die dasselbe Zertifikat verwenden, sodass alle nicht mehr funktionieren.

Damit die noch vertrauenswürdigen SharePoint-Add-Ins wieder funktionieren, muss der Administrator ein New-SPTrustedSecurityTokenIssuer Objekt mit einem neuen Zertifikat erstellen und das -IsTrustBroker Flag einschließen. Das neue Zertifikat müsste bei jedem Server registriert werden, der die vertrauenswürdigen Add-Ins hostet, und jedes dieser Add-Ins müsste an das neue Zertifikat gebunden werden.

Der Vorteil der Verwendung eines Zertifikats pro Add-In besteht darin, dass es einfacher ist, die Vertrauensstellung mit einem bestimmten Add-In aufzuheben, da die Zertifikate, die von den weiterhin vertrauenswürdigen Add-Ins verwendet werden, nicht beeinträchtigt werden, wenn der Administrator die Vertrauensstellung mit dem Zertifikat eines der Add-Ins auflöst. Der Nachteil bei dieser Strategie besteht darin, dass ein Administrator mehr Zertifikate erwerben muss, und SharePoint muss so konfiguriert werden, dass jedes dieser Zertifikate verwendet wird, was über ein wiederverwendbares Skript, wie in Besonders vertrauenswürdige Konfigurationsskripts für SharePoint dargestellt, erreicht werden kann.

Zertifikate sind Stammzertifizierungsstellen in SharePoint

Wie zu Beginn dieses Artikels kurz erwähnt, müssen SharePoint-Farmadministratoren dafür sorgen, dass das Zertifikat der Remotewebanwendung in dem Add-In mit hoher Vertrauenswürdigkeit eine vertrauenswürdige Stammzertifizierungsstelle in SharePoint und auch ein vertrauenswürdiger Tokenaussteller ist. Wenn es eine Hierarchie von Zertifikat ausstellenden Zertifizierungsstellen hinter dem Zertifikat der Webanwendung gibt, müssen alle Zertifikate in der Kette der SharePoint-Liste vertrauenswürdiger Stammzertifizierungsstellen hinzugefügt werden.

Jedes Zertifikat in der Kette wird der SharePoint-Liste der vertrauenswürdigen Stammautoritäten mit einem Aufruf des New-SPTrustedRootAuthority Cmdlets hinzugefügt. Angenommen, das Zertifikat der Webanwendung ist ein Domänenzertifikat, das von einer Unternehmensdomänenzertifizierungsstelle im LAN ausgestellt wird. Angenommen, das Zertifikat wurde wiederum von einer eigenständigen Zertifizierungsstelle der obersten Ebene im LAN ausgestellt. In diesem Szenario müssen die Zertifikate der obersten Zertifizierungsstelle, der Zwischenzertifizierungsstelle und der Webanwendung der SharePoint-Liste der vertrauenswürdigen Stammautoritäten hinzugefügt werden. Der folgende Windows PowerShell Code würde dies erreichen.

$rootCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<path_to_top-level_CA's_cer_file>")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $rootCA

$intermediateCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_intermediate_CA's_cer_file")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $intermediateCA

$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_web_application's_cer_file") 
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $certificate

Die Stamm- und Zwischenzertifikate sollten in einer SharePoint-Farm nur einmal hinzugefügt werden. In der Regel wird das Zertifikat der Webanwendung in einem separaten Skript hinzugefügt, das auch andere Konfigurationen vornimmt, z. B. der Aufruf von New-SPTrustedSecurityTokenIssuer. Beispiele finden Sie unter Konfigurationsskripts mit hoher Vertrauenswürdigkeit für SharePoint.

Wenn das Zertifikat der Webanwendung selbstsigniert ist, wie das z. B. der Fall ist, wenn das Add-In entwickelt und debuggt wird, gibt es keine Zertifikatskette, sodass nur das Zertifikat der Webanwendung der Liste der Stammauthentifizierungsstellen hinzugefügt werden muss.

Weitere Informationen finden Sie im Blogbeitrag Fehler: Dem Stamm der Zertifikatskette wird bei anspruchsbasierter Authentifizierung nicht vertraut. Überblättern Sie den Abschnitt zum Exportieren des Zertifikats aus Active Directory-Verbunddiensten, wobei davon ausgegangen wird, dass Sie Ihr Zertifikat für Ihre besonders vertrauenswürdigen Add-Ins auf anderem Weg erstellt haben, z. B. mithilfe eines durch eine Zertifizierungsstelle ausgestellten kommerziellen Zertifikats, eines selbstsignierten Zertifikats oder eines von der Domäne ausgestellten Zertifikats.

Die Webanwendung muss wissen, dass es sich um einen Tokenherausgeber handelt

Die Remotewebanwendungs-Komponente eines SharePoint-Add-Ins mit hoher Vertrauenswürdigkeit ist an ihr Zertifikat in IIS gebunden. Dies ist für die herkömmlichen Zwecke von Zertifikaten ausreichend: Sicheres Identifizieren der Webanwendung und Verschlüsseln der HTTP-Anforderungen und -Antworten.

In einem SharePoint-Add-In mit hoher Vertrauenswürdigkeit hat das Zertifikat jedoch eine weitere Aufgabe, und zwar ist es der offizielle „Aussteller“ der Zugriffstoken, die die Webanwendung an SharePoint sendet. Zu diesem Zweck muss die Webanwendung die Aussteller-ID des Zertifikats kennen, die verwendet wird, wenn das Zertifikat als Tokenherausgeber bei SharePoint registriert wird. Die Webanwendung ruft diese ID aus dem Abschnitt appSettings der Datei „web.config“ ab, in dem es einen Schlüssel mit dem Namen IssuerId gibt.

Anweisungen dazu, wie der Add-In-Entwickler diesen Wert festlegt und wie das Zertifikat an die Webanwendung in IIS gebunden wird, finden Sie unter Packen und Veröffentlichen besonders vertrauenswürdiger Add-Ins für SharePoint.

Beachten Sie Folgendes: Wenn der Kunde die Strategie eines separaten Zertifikats für jedes SharePoint-Add-In mit hoher Vertrauenswürdigkeit verfolgt, wird der ClientID-Wert auch als IssuerId-Wert verwendet. Dies ist nicht der Fall, wenn mehrere Add-Ins dasselbe Zertifikat verwenden, da jedes SharePoint-Add-In seine eigene eindeutige Client-ID haben muss, die Aussteller-ID ist jedoch der Bezeichner für ein SPTrustedSecurityTokenIssuer-Objekt.

Es folgt ein Beispiel für einen appSettings-Abschnitt für ein besonders vertrauenswürdiges SharePoint-Add-In. In diesem Beispiel wird ein Zertifikat von mehreren Add-Ins gemeinsam genutzt, sodass die IssuerId nicht mit der ClientId identisch ist. Beachten Sie, dass in einem besonders vertrauenswürdigen SharePoint-Add-In kein ClientSecret-Schlüssel vorhanden ist.

<appSettings>
  <add key="ClientId" value="6569a7e8-3670-4669-91ae-ec6819ab461" />
  <add key="ClientSigningCertificatePath" value="C:\MyCerts\HighTrustCert.pfx" />
  <add key="ClientSigningCertificatePassword" value="3VeryComplexPa$$word82" />
  <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965" />
</appSettings>

Hinweis

Im vorherigen Beispiel wird davon ausgegangen, dass das Zertifikat im Dateisystem gespeichert ist. Dies ist akzeptabel für Entwicklung und Debugging. In einem besonders vertrauenswürdigen SharePoint-Add-In für die Produktion wird das Zertifikat in der Regel im Windows-Zertifikatspeicher gespeichert, und die Schlüssel ClientSigningCertificatePath und ClientSigningCertificatePassword werden in der Regel durch einen ClientSigningCertificateSerialNumber-Schlüssel ersetzt.

Aufgaben der IT-Mitarbeiter im besonders vertrauenswürdigen System

Entwickler müssen die Anforderungen für Anwendungssicherheit, wie oben beschrieben, verstehen, während IT-Experten die Infrastruktur implementieren, die zur Unterstützung erforderlich ist. IT-Experten müssen die folgenden betrieblichen Anforderungen einplanen:

  • Erstellen oder Erwerben mindestens eines Zertifikats, das für vertrauenswürdige SharePoint-Add-Ins verwendet wird.

  • Sicherstellen, dass die Zertifikate sicher auf Webanwendungsserver gespeichert werden. Wenn das Windows-Betriebssystem verwendet wird, bedeutet dies, dass die Zertifikate im Windows-Zertifikatspeicher gespeichert werden.

  • Verwalten der Verteilung dieser Zertifikate an Entwickler, die SharePoint-Add-Ins erstellen.

  • Nachverfolgen, wo jedes Zertifikat verteilt wird, sowohl für Add-Ins, die es verwenden, als auch für die Entwickler, die eine Kopie erhalten haben. Wenn ein Zertifikat widerrufen werden muss, müssen die IT-Mitarbeiter mit jedem einzelnen Entwickler arbeiten, um einen verwalteten Übergaben zu einem neuen Zertifikat sicherzustellen.

Siehe auch