Einrichten einer oAuth-Vertrauensstellung zwischen Farmen in SharePoint 2013
Veröffentlichung des Originalartikels: 23.07.2012
Eines der Themen, über das Sie im Zusammenhang mit SharePoint 2013 wahrscheinlich viel hören werden und ich möglicherweise auch noch viel schreiben werde, ist oAuth. In SharePoint 2013 wird oAuth verwendet, um eine Vertrauensstellung zwischen zwei Anwendungen herzustellen und damit die Identität eines Prinzipals (Benutzer oder Anwendung) festzulegen. In SharePoint verwenden Sie oAuth-Vertrauensstellung zwischen SharePoint und beispielsweise Exchange und Lync, mit ACS oder einzelnen Anwendungsentwicklern, die das neue Cloud-App-Modell verwenden, oder sogar zwischen zwei unterschiedlichen SharePoint-Farmen für Aspekte wie SharePoint-Remoteindizes für Suchvorgänge.
oAuth kann NICHT als Authentifizierungsanbieter für Personen eingesetzt werden. Sie müssen weiterhin New-SPTrustedIdentityTokenIssuer verwenden, um diese Vertrauensstellungen für Ihre Identitätsanbieter zu erstellen. Für oAuth-Vertrauensstellungen ist ein neues Cmdlet mit einem sehr ähnlichen Namen vorhanden: New-SPTrustedSecurityTokenIssuer. Wenn eine Vertrauensstellung dieser Art mit einem Sicherheitstokenaussteller hergestellt wird, bezeichnen wir dies als S2S-Vertrauensstellung (Server zu Server). Prägen Sie sich dieses Akronym gut ein, in SharePoint 2013 wird es häufig verwendet werden. In diesem Beitrag werde ich einige Voraussetzungen zum Herstellen einer solchen Vertrauensstellung erläutern.
Ich halte es für erwähnenswert, dass viele Features, für die eine S2S-Vertrauensstellung erforderlich ist, diese Vertrauensstellung selbst herstellen. Dies kann über die Aktivierung des Features erfolgen, oder das betreffende Featureteam stellt ein PowerShell-Skript oder Cmdlet bereit, das die Vertrauensstellung im Rahmen der Featureaktivierung herstellt. In anderen Situationen müssen Sie diese Aufgabe aber selbst übernehmen, und dies ist das Thema dieses Beitrags.
Zunächst müssen Sie festlegen, ob Sie SSL verwenden oder nicht. Tatsächlich ist es so, dass Sie für SharePoint 2013 in den meisten Fällen SSL verwenden sollten. Ich sage dies, weil in vielen SharePoint 2013-Szenarien oAuth verwendet wird; dabei werden Cookies mit Zugriffstoken übermittelt. Ein Zugriffstoken lässt sich mit einem Schlüssel vergleichen, mit dem Sie das Tor zu Ihren Daten entriegeln können. Der Zugriffstoken ist mit einem Zertifikat signiert, kann also nicht von jemandem gefälscht werden, der einfach einen eigenen Zugriffstoken erstellt. Allerdings ist es ungünstig, den Cookie im Klartext zu übertragen, weil es zumindest theoretisch möglich ist, dass eine andere Person den Cookie abfängt und für die Lebensdauer des Cookies wiederverwendet. SSL schützt Sie vor einem derartigen Replay-Angriff auf dieselbe Art und aus denselben Gründen wie SSL bei einer Authentifizierungswebsite mit Formularen. Trotzdem kann es Gründe geben, warum Sie Ihre Websites über HTTP betreiben möchten: Sie haben eine Testumgebung, Sie arbeiten in einer Entwicklungsumgebung, die Website ist vollständig auf ein internes Netzwerk beschränkt und ist daher Ihrer Meinung nach keinem Risiko ausgesetzt usw. Ich möchte das alles gar nicht verurteilen, sondern nur erklären.
SCHRITT 1: Konfigurieren des STS
Die Konfiguration des SharePoint-Sicherheitstokendiensts (STS) umfasst einige Einstellungen, die Sie möglicherweise anpassen sollten, wenn Sie kein SSL verwenden. Mit dem Cmdlet Get-SPSecurityTokenServiceConfig können Sie alle STS-Konfigurationseinstellungen abrufen. Eine Vertrauensstellung lässt sich auf zwei Arten herstellen: mit einem Zertifikat oder mit einem neuen oAuth-Metadatenendpunkt, der auf allen SharePoint-Farmen zu finden ist. Ein Metadatenendpunkt ist einfacher zu verwenden, aber wenn der Endpunkt nicht durch SSL geschützt ist, müssen Sie die AllowMetadataOverHttp-Eigenschaft des SharePoint-STS auf „true“ festlegen. Wenn Sie Ihre Web Apps nicht über SSL ausführen, müssen Sie die AllowOAuthOverHttp-Eigenschaft ebenfalls auf „true“ festlegen. Das folgende PowerShell-Skript veranschaulicht, wie diese Eigenschaften festgelegt werden:
$c = Get-SPSecurityTokenServiceConfig
$c.AllowMetadataOverHttp = $true
$c.AllowOAuthOverHttp= $true
$c.Update()
SCHRITT 2: Herstellen der Vertrauensstellung
Nachdem der STS wie gewünscht konfiguriert wurde, kann die Vertrauensstellung zwischen zwei Farmen hergestellt werden. Ich habe weiter oben bereits erwähnt, dass alle SharePoint-Farmen jetzt einen Metadatenendpunkt aufweisen; er wird verwendet, um Informationen und das Tokensignaturzertifikat bereitzustellen. Der Metadatenendpunkt befindet sich unter "/_layouts/15/metadata/json/1". Sollten Sie tatsächlich versuchen, in einem Browser an diesen Speicherort zu navigieren, werden Sie zum Speichern aufgefordert – so könnten Sie den Endpunkt untersuchen. Wenn Sie den Endpunkt in Editor öffnen, werden Sie feststellen, dass es sich lediglich um eine JSON-Nutzlast handelt. Die Datei enthält den Namensbezeichner des STS (der „issuer“) und eine serialisierte Version des Tokensignaturzertifikats (der Wert des Schlüssels „x509certificate“). Wenn Sie die Daten etwas genauer anschauen, stellen Sie weiterhin fest, dass der Aussteller aus dem Dienstnamen + „@“ + dem Bereich besteht. Er entspricht außerdem der NameIdentifier-Eigenschaft des STS; aus später zu erläuternden Gründen ist diese Information wichtig.
Nehmen Sie für dieses Beispiel an, dass FARM_B Aufrufen von FARM_A vertrauen soll, weil FARM_A FARM_B als SharePoint-Remoteindex verwendet. Außerdem liegt auf FARM_A unter https://FARM_A eine Webanwendung vor. Um die Vertrauensstellung herzustellen, rufen Sie das New-SPTrustedSecurityTokenIssuer-Cmdlet folgendermaßen auf einem Server in FARM_B auf (ich erläutere später, warum ich Ausdrücke wie „$i = “ verwende):
$i = New-SPTrustedSecurityTokenIssuer -Name FARM_A -Description "FARM_A description" -IsTrustBroker:$false -MetadataEndPoint "https://FARM_A/_layouts/15/metadata/json/1"
Nehmen Sie nun an, dass Sie eine Vertrauensstellung mit einer Farm einrichten, die nur Dienste bereitstellt. Sie legen keinen besonders großen Wert darauf, eine Webanwendung, eine Websitesammlung und ein SSL-Zertifikat zu erstellen, nur damit Sie daraus die Vertrauensstellung herstellen können. Daher gibt es eine weitere Methode dafür: das New-SPTrustedSecurityTokenIssuer-Cmdlet. In der zweiten Vorgehensweise reicht es aus, das Tokensignaturzertifikat und den Namensbezeichner anzugeben. Sie erhalten das Tokensignaturzertifikat genau wie in SharePoint 2010: Rufen Sie auf einem Server in der Farm die MMC auf, fügen Sie das Zertifikate-Snap-In für den lokalen Computer hinzu, und schauen im Knoten „SharePoint…Zertifikate“ (SharePoint…Certificates) nach – es ist gleich das erste Zertifikat in der Liste. Speichern Sie dieses Zertifikat ohne den privaten Schlüssel als CER-Datei auf dem lokalen Laufwerk. Sie benötigen das Zertifikat und das NameIdentifier-Attribut des STS, das ich weiter oben erläutert habe, um die Vertrauensstellung herzustellen. Das Cmdlet wird in diesem Fall wie folgt aufgerufen (unter der Annahme, dass Sie das STS-Zertifikat in der Datei „C:sts.cer“ auf einem Server in FARM_B gespeichert haben):
$i = New-SPTrustedSecurityTokenIssuer -name FARM_A -Certificate "C:sts.cer" -RegisteredIssuerName "00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef " -Description "FARM_A description" -IsTrustBroker:$false
SCHRITT 3: Herstellen der Vertrauensstellung mit dem Tokensignaturzertifikat
Genau wie bei einem SPTrustedIdentityTokenIssuer müssen Sie die Vertrauensstellung, mit der Sie oAuth-Tokens signieren, zur Liste der vertrauenswürdigen Stammzertifizierungsstellen in SharePoint hinzufügen. Auch hierbei haben Sie zwei Möglichkeiten. Wenn Sie die Vertrauensstellung über den Metadatenendpunkt erstellen, können Sie die Vertrauensstellung folgendermaßen herstellen:
New-SPTrustedRootAuthority -Name FARM_A -MetadataEndPoint https://FARM_A/_layouts/15/metadata/json/1/rootcertificate
Andernfalls können Sie sie genau wie in SharePoint 2010 zur Liste der vertrauenswürdigen Stammzertifizierungsstellen hinzufügen:
$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:sts.cer")
New-SPTrustedRootAuthority -Name "Token Signing Root CA Certificate" -Certificate $root
In Bezug auf die Vertrauensstellung sind Sie jetzt fertig. Die Vertrauensstellung wurde hergestellt, und Sie können auf deren Basis neue Anwendungsprinzipale erstellen. Wie Sie sie einsetzen, hängt von der Anwendung selbst ab. Für einen SharePoint-Remoteindex werde ich das Szenario jetzt der Vollständigkeit halber komplettieren.
SCHRITT 4: Erstellen eines Anwendungsprinzipals (Beispiel nur für SharePoint-Remoteindex):
Zwei Schritte werden benötigt: Sie müssen einen Anwendungsprinzipal abrufen und diesem Rechte gewähren. Nur zur Erinnerung: In diesem Szenario muss FARM_B Aufrufen von FARM_A vertrauen, weil Sie Abfragen für den SharePoint-Remoteindex erhält. Für den Anwendungsprinzipal muss ich also einen Verweis auf die Web App in FARM_B abrufen, den FARM_A verwenden wird. Wenn ich diesen Verweis habe, kann ich FARM_A Rechte zuteilen, damit sie ihn verwenden kann.
Zum Abrufen eines Verweises auf einen Anwendungsprinzipal verwenden Sie das Cmdlet folgendermaßen:
$p = Get-SPAppPrincipal -Site https://FARM_B -NameIdentifier $i.NameId
WICHTIG: Hierbei gibt es einen wichtigen Aspekt zu beachten, der meiner Meinung nach insbesondere in der SharePoint 2013-Betaphase häufig auftreten wird. Möglicherweise erhalten Sie merkwürdige Fehler in PowerShell, wenn Sie versuchen, den SPAppPrincipal abzurufen. Ich habe festgestellt, dass alle WCF-Aufrufe fehlschlagen, sobald weniger als 5 % des Arbeitsspeichers auf Ihrem Server verfügbar sind. Da bei diesem PowerShell-Cmdlet Aufrufe in einen Dienstanwendungsendpunkt erfolgen, der als WCF gehostet wird, schlägt das Get-SPAppPrincipal-Cmdlet fehl, wenn nur noch wenig Speicherplatz verfügbar ist. Sie können in der Windows-Ereignisanzeige im Anwendungsprotokoll nachschlagen, ob dies bei Ihnen ein Problem verursacht. Mir ist das bereits häufig passiert, daher denke ich, dass dies auch bei anderen auftreten wird.
Jetzt kann ich endlich die früher in diesem Beitrag beschrieben Variable „$i“ verwenden, um den NameIdentifier des STS in FARM_A abzurufen. Diesem Verweis auf den Anwendungsprinzipal für die Web App in FARM_B kann ich folgendermaßen Rechte gewähren:
Set-SPAppPrincipalPermission -Site https://FARM_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl
Das war's auch schon. Dies sind Ihre Optionen und Verfahren, um eine oAuth-Vertrauensstellung zwischen zwei SharePoint-Farmen zu erstellen. Ich werde mich in diesem Blog künftig weiterhin mit oAuth und den verschiedenen Verwendungsmöglichkeiten und zu beachtenden Problemen beschäftigen.
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Setting Up an oAuth Trust Between Farms in SharePoint 2013