Endlich eine SINNVOLLE Möglichkeit, über OAuth und SAML einen Verbund mit Windows Live und SharePoint 2010 einzurichten

  • Article

Veröffentlichung des Originalartikels: 01.03.2012

Viele Leute haben sich in letzter Zeit mit mir über einen Verbund zwischen SharePoint und Windows Live unterhalten. Oberflächlich betrachtet, scheint es sich um eine gute Idee zu handeln. Windows Live hat viele Millionen Nutzer, die sich alle mit ihrer E-Mail-Adresse anmelden, die wir häufig als Identitätsanspruch verwenden. Es handelt sich um einen großen skalierbaren Dienst, und es gibt mittlerweile verschiedene Anweisungen zu seiner Nutzung – entweder direkt oder über ACS (Access Control Service). Aber warum habe ich so viele Vorbehalte gegenüber seiner Nutzung mit SharePoint? Nun diejenigen unter Ihnen, die es bereits ausprobiert haben, wissen, dass man bei einem Verbund mit Windows Live nie die E-Mail-Adresse eines Benutzers als Anspruch zurückbekommt. Alles, was man erhält, ist eine spezielle Windows Live-ID, die PUID genannt wird. Soweit ich weiß, steht PUID für "Practically GUID" (praktisch eine GUID), was Auskunft über ihr Aussehen und ihren Zweck gibt.

Wie können Sie, wenn Sie doch einen Verbund mit Windows Live einrichten, eine Person einer Website hinzufügen? Sie müssen ihre PUID abrufen und diese anschließend einer SharePoint-Gruppe oder -Berechtigungsstufe hinzufügen. Kennen Sie ernsthaft jemanden, der seine PUID kennt (wenn Sie so jemand sind, wird's Zeit, sich ein anderes Hobby zu suchen). Selbst wenn Sie trotz allem Ihre PUID kennen sollten, wie nützlich ist diese Info, wenn Sie versuchen, Benutzern Rechte für verschiedene Websitesammlungen zu erteilen? Glauben Sie wirklich, dass jemand Sie in einer PUID-Liste (z. B. in der Personenauswahl) auswählen könnte? Natürlich nicht! Dies ist eine weitere frustrierende Ursache meiner Vorbehalte.

Ich dachte eigentlich, dass wir uns hier an eine utopischere Lösung mit ACS heranwagen könnten. ACS eignet sich wird gut für das Bereitstellen standardmäßiger Schnittstellen mit mehreren Identitätsanbietern wie Windows Live, Google, Yahoo und Facebook. Mit Facebook kommt sogar ein wenig Magie ins Spiel, indem OAuth zum Authentifizieren verwendet und anschließend eine Gruppe von SAML-Ansprüchen zurückgegeben wird. Voll cool! Warum geschieht dasselbe nicht bei Windows Live? Windows Live unterstützt jetzt auch OAuth, sodass es scheint, dass sich letztlich eine Chance für eine nützliche Entwicklung ergibt. Doch auch wenn ich es mir noch so wünsche, kommen mir hier die ACS-Leute nicht zur Hilfe. Was letztendlich der eigentliche Punkt dieses Vorworts ist, denn ich habe beschlossen, mir eine eigene Lösung zu basteln, die ich in diesem Beitrag vorstellen möchte.

Warum beschäftigen wir uns überhaupt mit OAuth? Nun im Gegensatz zur PUID, die wir bei einem direkten Verbund mit Windows Live erhalten, lässt die OAuth-Unterstützung in Windows Live das Abrufen von WESENTLICH mehr Informationen über den Benutzer zu, einschließlich seiner (man mag es kaum glauben) E-Mail-Adresse. Deshalb sieht der Angriffsplan im Wesentlichen so aus:

  1. Schreiben eines benutzerdefinierten Identitätsanbieters mithilfe von Windows Identity Foundation (WIF).
  2. Wenn eine Person zu unseren Sicherheitstokendienst umgeleitet wird, leiten wir sie, wenn noch keine Authentifizierung erfolgt ist, wieder zu Windows Live um. Hierzu müssen wir "eine Anwendung" mit Windows Live erstellen, was weiter unten detailliert erläutert wird.
  3. Nach der Authentifizierung wird die Person wieder zu unseren angepassten Sicherheitstokendienst umgeleitet. Anschließend enthält die Abfragezeichenfolge ein Anmeldetoken, das gegen ein Zugriffstoken ausgetauscht werden kann.
  4. Der Sicherheitstokendienst stellt dann im Anmeldecode eine weitere Anforderung an Windows Live nach einem Zugriffstoken.
  5. Nach Erhalten des Zugriffstokens erfolgt eine letzte Anforderung an Windows Live mit dem Zugriffstoken nach einigen grundlegenden Informationen zum Benutzer (weiter unten mehr dazu, was zurückgegeben wird).
  6. Nachdem wir die Benutzerinformationen von Windows Live zurückerhalten haben, erstellen wir mithilfe unseres angepassten Sicherheitstokendiensts eine Gruppe von SAML-Ansprüchen für den Benutzer und füllen diese mit Benutzerinformationen auf. Dann lassen wir eine Umleitung zurück zu der Anwendung erfolgen, die uns zur Authentifizierung aufgefordert hat, damit diese die gewünschten Aufgaben mit den SAML-Token erledigen kann. In diesem besonderen Fall habe ich meinen Sicherheitstokendienst sowohl mit einer standardmäßigen ASP.NET-Anwendung als auch einer SharePoint 2010-Webanwendung getestet.

Den gesamten Quellcode habe ich diesem Beitrag hinzugefügt. Dennoch müssen noch einige Konfigurationsaufgaben ausgeführt werden, und Sie müssen die Anwendung mit der Anwendungs-ID und dem geheimen Schlüssel neu kompilieren, den Sie von Windows Live erhalten. Doch neben dem Kopieren und Einfügen des Codes müssen Sie keinen weiteren Code für diese Lösung schreiben. Lassen Sie uns nun alle erforderlichen Schritte für seine Nutzung durchgehen.

Erstellen eines Tokensignaturzertifikats

Sie müssen ein Zertifikat zum Signieren Ihrer SAML-Token erstellen. Für das Zertifikat zum Signieren von Zertifikaten gelten keine besonderen Anforderungen, außer dass Sie sicherstellen müssen, dass Sie über den privaten Schlüssel dafür verfügen. Ich in meinem Fall habe in meiner Domäne Zertifikatdienste installiert, sodass ich lediglich den IIS-Manager öffnen und die Option zum Erstellen eines Domänenzertifikats wählen musste. Ich befolgte die Anweisungen des Assistenten und hatte ruck zuck ein neues Zertifikat samt privatem Schlüssel. Für dieses Projekt habe ich das Zertifikat "livevbtoys" erstellt.

Wenn, wie ich im nächsten Abschnitt erkläre, Anforderungen anfänglich in den Sicherheitstokendienst gelangen, ist der Benutzer anonym. Damit dieses Zertifikat zum Signieren von SAML-Token verwendet werden kann, müssen wir dem privaten Schlüssel den IIS-Prozesszugriff für dieses Zertifikat gewähren. Wenn eine anonyme Anforderung eingeht, heißt die IIS-Prozessidentität Netzwerkdienst. Um diese mit Rechten für den Schlüssel zu versehen, müssen Sie:

  1. Die MMC starten.
  2. Das Snap-In Zertifikate hinzufügen. Wählen Sie für den lokalen Computer den Zertifikatspeicher Computer aus.
  3. Öffnen Sie den Zertifikatspeicher Eigene Zertifikate, und wechseln Sie zum Zertifikat, das Sie für das Signieren von SAML-Token erstellt haben. Wenn Sie das Zertifikat wie zuvor beschrieben erstellt haben, befindet es sich standardmäßig dort. Wenn Sie es auf andere Weise erstellt haben, müssen Sie es ggf. diesem Speicher hinzufügen.
  4. Klicken Sie mit der rechten Maustaste auf das Zertifikat, und wählen Sie die Option Private Schlüssel verwalten.
  5. Fügen Sie in der Liste der Benutzer mit Rechten für die Schlüssel Netzwerkdienst hinzu, und erteilen Sie hierfür Leseberechtigungen.

Wenn Sie diese Schritte nicht ordnungsgemäß ausführen, erhalten Sie beim Ausführen der Anwendung ggf. die Fehlermeldung "Der Schlüsselsatz ist nicht vorhanden". Dies bedeutet lediglich, dass der IIS-Prozess nicht genügend Rechte für den privaten Schlüssel besitzt, sodass dieser nicht zum Signieren des SAML-Tokens verwendet werden konnte.

Die Anwendung und benötigten Assemblys installieren

Das Installieren der Anwendung bedeutet in diesem Kontext lediglich das Erstellen einer ASP.NET-Anwendung, das Kopieren des Codes und das Sicherstellen, dass die neueste WIF-Version installiert ist. Nach der Konfiguration und Inbetriebnahme auf einem Server sollten Sie einen oder mehrere Server hinzufügen, um für eine fehlertolerante Lösung zu sorgen. Hier stelle ich allerdings nur die auf dem einzelnen Server benötigte Konfiguration vor.

Nicht erklären werde ich hier das Erstellen einer ASP.NET-Anwendung in IIS, was in Visual Studio, im IIS-Manager usw. erfolgen kann.

HINWEIS: Wenn Sie den hier angegebenen Code verwenden und das Projekt in Visual Studio öffnen, wird angemeckert, dass der Host oder die Website nicht vorhanden ist. Der Grund ist, dass der Name meines Servers verwendet wird. Die einfachste Möglichkeit zur Korrektur ist das manuelle Bearbeiten der Datei WindowsLiveOauthSts.sln und Ändern der HTTPS-Werte in diejenigen Ihrer Umgebung.

Sobald dies erfolgt ist, sollten Sie einige wichtige Aufgaben erledigen.

  1. Fügen Sie im IIS-Manager PassiveSTS.aspx als Standarddokument für die Sicherheitstokendienst-Website hinzu.
  2. Ändern Sie in IIS die Authentifizierungseinstellungen für die Anwendung so, dass alle Authentifizierungstypen außer Anonyme Authentifizierung deaktiviert sind.
  3. Der Sicherheitstokendienst muss über SSL ausgeführt werden, weshalb Sie hierfür ein entsprechendes Zertifikat beziehen und die Bindungen auf dem virtuellen IIS-Server aktualisieren müssen, auf dem die angepasste Sicherheitstokendienst-Anwendung verwendet wird.
  4. Fügen Sie den Fingerabdruck des Tokensignaturzertifikats dem Thumbprint-Attribut des Add-Elements im Abschnitt trustedIssuers der Datei web.config der vertrauenden Seite hinzu (wenn Sie NICHT SharePoint zum Testen verwenden). Wenn Sie in Visual Studio den Assistenten zum Hinzufügen eines Sicherheitstokendienst-Verweises verwenden, führt dieser diese Schritte aus.

In IIS ist ansonsten keine weitere Konfiguration erforderlich.

Aktualisieren und Erstellen des angepassten Sicherheitstokendienst-Projekts

Die angefügte ZIP-Datei enthält das Visual Studio 2010-Projekt WindowsLiveOauthSts. Nachdem Sie IIS konfiguriert und die Datei WindowsLiveOauthSts (wie zuvor beschrieben) aktualisiert haben, sollten Sie das Projekt in Visual Studio öffnen können. Anschließend müssen Sie als Erstes die Konstanten CLIENT_ID und CLIENT_SECRET in der Klasse PassiveSTS.aspx.cs aktualisieren. (Sie erhalten diese beim Erstellen einer neuen Windows Live-Anwendung.) Dieser Vorgang wird hier nicht im Einzelnen behandelt (da es bei Windows Live Leute gibt, die Ihnen dabei helfen können). Ich möchte lediglich auf den Speicherort hinweisen, an dem Sie Ihre Windows Live-Anwendung erstellen können: https://manage.dev.live.com/Applications/Index?wa=wsignin1.0. Außerdem müssen Sie beim Erstellen Ihrer Anwendung die Umleitungsdomäne auf den Speicherort festlegen, an dem Ihr angepasster Sicherheitstokendienst gehostet wird. Beispiel: https://myserver.foo.com.

Nun da Sie über Ihre ID und den geheimen Schlüssel verfügen, muss Folgendes in der Anwendung aktualisiert werden:

  1. Die Konstanten CLIENT_ID und CLIENT_SECRET in der Klasse PassiveSTS.aspx.cs.
  2. Die Angabe für SigningCertificateName im Abschnitt appSettings der Datei web.config. Die Einstellung IssuerName kann, muss aber nicht geändert werden.
  3. Das Tokensignaturzertifikat für das Dokument FederationMetadata.xml im Sicherheitstokendienst-Projekt. Nachdem Sie das zu verwendende Zertifikat ausgewählt haben, können Sie mithilfe der zu diesem Beitrag gehörenden Anwendung test.exe den Zeichenfolgenwert des Zertifikats abrufen. Dieser muss zum Ersetzen der beiden Werte des Elements X509Certificate in der Datei federationmetadata.xml kopiert werden.

Hier noch ein weiterer wichtiger Hinweis. In der Datei CustomSecurityTokenService.cs können Sie die Variable enableAppliesToValidation auf True festlegen und anschließend eine Liste der URLs angeben, die diesen angepassten Sicherheitstokendienst verwenden können. In meinem Fall habe ich mich gegen jedwede Einschränkung entschieden, weshalb die Variable auf False festgelegt ist. Wenn Sie Ihren angepassten Sicherheitstokendienst sperren möchten, sollten Sie diese Einstellung jetzt ändern. Nachdem alle diese Änderungen erfolgt sind, können Sie die Anwendung erneut kompilieren und anschließend einsetzen.

Und hier noch ein Hinweis. Ich habe auch eine ASP.NET-Beispielanwendung hinzugefügt, die ich bei dieser Entwicklung für Testzwecke verwendet habe und in einem Projekt mit dem Namen "LiveRP" enthalten ist. Ich werde sie nicht weiter vorstellen und wollte nur anmerken, dass sie zur Verfügung steht, wenn Sie Dinge ausprobieren möchten. Vergessen Sie nicht (wie zuvor erwähnt), den Fingerabdruck des Tokensignaturzertifikats des Sicherheitstokendiensts zu ändern.

SharePoint-Konfiguration

An dieser Stelle ist alles konfiguriert und sollte für den angepassten Sicherheitstokendienst funktionieren. Jetzt muss nur noch ein neuer Wert für SPTrustedIdentityTokenIssuer in SharePoint erstellt und eine neue oder vorhandene Webanwendung für dessen Nutzung konfiguriert werden. Beim Konfigurieren von SPTrustedIdentityTokenIssuer gilt es allerdings, verschiedene Dinge zu beachten. Ich stelle Ihnen die PowerShell-Befehlszeilen bereit, die ich zum Erstellen meines Werts verwendet habe, die ich anschließend erläutere:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:livevbtoys.cer")

New-SPTrustedRootAuthority -Name "SPS Live Token Signing Certificate" -Certificate $cert

 

$map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/id" -IncomingClaimTypeDisplayName "WindowsLiveID" -SameAsIncoming

$map3 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/full_name" -IncomingClaimTypeDisplayName "FullName" -SameAsIncoming

$map4 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/first_name" -IncomingClaimTypeDisplayName "FirstName" -SameAsIncoming

$map5 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/last_name" -IncomingClaimTypeDisplayName "LastName" -SameAsIncoming

$map6 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/link" -IncomingClaimTypeDisplayName "Link" -SameAsIncoming

$map7 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/gender" -IncomingClaimTypeDisplayName "Gender" -SameAsIncoming

$map8 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/locale" -IncomingClaimTypeDisplayName "Locale" -SameAsIncoming

$map9 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/updated_time" -IncomingClaimTypeDisplayName "WindowsLiveLastUpdatedTime" -SameAsIncoming

$map10 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/account" -IncomingClaimTypeDisplayName "AccountName" -SameAsIncoming

$map11 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/accesstoken" -IncomingClaimTypeDisplayName "WindowsLiveAccessToken" -SameAsIncoming

$realm = "https://spslive.vbtoys.com/_trust/"

$ap = New-SPTrustedIdentityTokenIssuer -Name "SpsLive" -Description "Window Live oAuth Identity Provider for SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3,$map4,$map5,$map6,$map7,$map8,$map9,$map10,$map11 -SignInUrl "https://spr200.vbtoys.com/WindowsLiveOauthSts/PassiveSTS.aspx" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

Hier nun einige Punkte, die zu beachten sind:

  1. Wie zuvor angegeben, habe ich das Zertifikat livevbtoys.cer zum Signieren meiner Token erstellt, weshalb ich es meiner Liste SPTrustedRootAuthority hinzugefügt und anschließend meinem Tokenaussteller zugeordnet habe.
  2. Ich habe Anspruchszuordnungen für alle meine Ansprüche erstellt, die mein angepasster Sicherheitstokendienst zurückgibt. Wie Sie erkennen können, ist dies wesentlich sinnvoller als ein Direktverbund mit Windows Live. Und hier noch ein weiterer Hinweis. Ich habe das Zugriffstoken, das ich von Windows Live erhalten habe, hier als Anspruch hinzugefügt. Während dies mit Facebook funktioniert, habe ich nicht getestet, ob es sich mit Windows Live wiederverwenden lässt. Dies wird aber vielleicht demnächst ein Thema eines neuen Blogbeitrags.
  3. Der Wert $realm ist überaus wichtig und muss auf die Stammwebsite Ihrer Webanwendung verweisen und das Verzeichnis /_trust/ enthalten. Wenn Sie hier einen Fehler machen, erhalten Sie bei einer erneuten Umleitung nach der Authentifizierung von SharePoint Fehlermeldungen vom Typ 500.
  4. Der –SignInUrl-Parameter ist beim Erstellen des Tokenausstellers die absolute URL zur Seite PassiveSTS.aspx meines angepassten Sicherheitstokendiensts.

Das wär's dann auch schon fast. Nach der Einrichtung verwenden Sie weiter die standardmäßige(n) Personenauswahl und Anspruchsanbieter, sodass Sie nicht, wie ggf. erwartet, über Nachschlagefunktionen verfügen. Sie gewähren Personen mit den E-Mail-Adressen, die diese zum Anmelden an Windows Live verwenden, Rechte. Sie können dieses Beispiel sogar auch auf den Azure-Anspruchsanbieter ausdehnen, zu dem ich folgenden Blogbeitrag verfasst habe: https://blogs.msdn.com/b/sharepoint_de/archive/2012/03/07/projekt-benutzerdefinierter-azure-anspruchsanbieter-f-252-r-sharepoint-teil-1.aspx. Sie können sich also mit diesem Sicherheitstokendienst bei Windows Live authentifizieren und einige tatsächliche SAML-Ansprüche zurückerhalten. Anschließend können Sie mithilfe des angepassten Azure-Anspruchsanbieterprojekts diese authentifizierten Benutzer Ihrem Azure-Verzeichnisspeicher hinzufügen und sie in der Personenauswahl auswählen.

Die folgenden Abbildungen veranschaulichen alle diese Abläufe beim ersten Besuch der SharePoint-Website und Authentifizierung bei Windows Live:

Bei der ersten Anmeldung werden Sie gefragt, ob es in Ordnung ist, dass Ihre Informationen mit der angepassten Sicherheitstokendienst-Anwendung gemeinsam genutzt werden. Bei diesen OAuth-Standardberechtigungseinstellungen gibt es keine Besonderheiten. Dieses Fenster sieht so aus und enthält die Daten, die ich im Sicherheitstokendienst anfrage. Sie können, falls gewünscht, gänzlich andere Daten anfordern. Im Window Live OAuth SDK können Sie nachschauen, was wie geändert werden muss:

Sobald Sie akzeptieren, werden Sie zurück zur SharePoint-Website umgeleitet. In diesem Beispiel verwende ich das SharePoint-Anspruchswebpart, über das ich bereits einen Beitrag verfasst habe: https://blogs.technet.com/b/speschka/archive/2010/02/13/figuring-out-what-claims-you-have-in-sharepoint-2010.aspx. Sie können alle Ansprüche sehen, die ich von Windows Live über OAuth erhalten habe und die nun dank meines angepassten Sicherheitstokendiensts als SAML-Ansprüche fungieren und erkennen, dass ich mit meiner Windows Live-E-Mail-Adresse angemeldet bin, die ich für dieses Projekt erstellt haben (siehe in der Abbildung rechts oben):

 

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Finally A USEFUL Way to Federate With Windows Live and SharePoint 2010 Using OAuth and SAML