SAML-basierte Verbundauthentifizierung mit SharePoint 2010 und Azure Access Control Service, Teil 1

Article
06/27/2011

Veröffentlichung des Originalartikels: 06.05.2011

BEMERKUNG AM RANDE: Wie immer ist die Formatierung auf dieser Website unglaublich mies. Zur einfacheren Lektüre empfehle ich deshalb, das diesem Beitrag angefügte Word-Dokument herunterzuladen.

Mit Interesse habe ich mir in letzter Zeit Windows Azure Access Control Service (ACS) angeschaut und Gedanken über einige Integrationsoptionen gemacht. Es wurde immer schon viel über die anspruchsbasierte Authentifizierung mit SharePoint 2010 sowie die Integration mit AD FS, Windows Live und Facebook usw. geredet. ACS (bei Azure-Puristen und Marketingexperten auch als AppFabric ACS bekannt) ist ziemlich cool, da schlüsselfertige "Konnektoren" für diese weit verbreiteten Identitätsanbieter bereitgestellt werden. Wenn Sie einen ACS-Namespace einrichten (was Sie sich als ein Konto mit Konnektoren und Konfigurationseinstellungen vorstellen können), vereinfachen und optimieren Sie die Konnektivität mit den Active Directory-Verbunddiensten 2.0 (Active Directory Federated Services, AD FS), Windows Live, Yahoo, Google und Facebook. Der faule Programmierer in mir überlegt sich dabei natürlich, welche Möglichkeiten sich daraus ergeben und deshalb habe ich mich entschieden, mir die Sache aus verschiedenen Betrachtungswinkeln mal anzusehen.. Die erste Art der Betrachtung wird hier in diesem Beitrag beschrieben.

Für dieses Szenario muss zunächst eine direkte Vertrauensstellung zwischen SharePoint 2010 und ACS hergestellt werden. Ich wollte ADFS-, Windows Live-, Yahoo- und Google-Konten für die Authentifizierung und den Zugriff auf meine SharePoint-Website verwenden. Facebook habe ich dabei nicht eingeschlossen, da soziale Netzwerke nicht wirklich mein Fall sind (mehr als dieser Blog ist bei mir nicht drin). Ich besitze also weder ein Facebook- noch ein Twitter-Konto, da ich kein Interesse habe, oft sinnlose Informationen an die Außenwelt weiterzugeben (“Minka hat 3 niedliche Kätzchen zur Welt gebracht - so süß!! ”). Ich erkläre hier übrigens NICHT, wie man ein Windows Azure-Konto erstellt, einen Access Control Service-Namespace erstellt und ACS verwaltet wird usw. - es gibt schon Unmengen an solchen Infos von den Windows Azure-Leuten, somit möchte ich uns eine Wiederholung ersparen.

Ich werde hier den Vorgang des Einrichtens verschiedener Vertrauensstellungen, Zertifikate und Konfigurationseinstellungen beschreiben, die für die richtige Integration dieser Elemente notwendig sind. Am Ende füge ich einige Bildschirmfotos an, die zeigen, wie ich mich über die einzelnen Anbieter angemeldet habe. So stellen Sie eine Verbindung her:

Öffnen Sie die Verwaltungsseite für Access Control
1. Melden Sie sich bei Ihrem Windows Azure-Verwaltungsportal an. Klicken Sie im linken Bereich auf das Menü Service Bus, Access Control and Caching. Klicken Sie am oberen Rand des linken Bereichs (unter AppFabric) auf Access Control, klicken Sie im rechten Bereich auf Ihren Namespace und anschließend im Abschnitt Manage des Menübands auf die Schaltfläche Access Control Service. So wird die Verwaltungsseite für Access Control aufgerufen.
Fügen Sie einen Identitätsanbieter für AD FS hinzu
1. Klicken Sie im linken Bereich im Menü Trust relationships auf Identity providers.
2. Klicken Sie auf die Verknüpfung Add.
3. Das Optionsfeld für den Identitätsanbieter WS-Federation sollte standardmäßig aktiviert sein. Überprüfen Sie, ob dies der Fall ist. Diese Option wird für AD FS 2.0 verwendet. Klicken Sie auf die Schaltfläche Next.
4. Füllen Sie den Abschnitt Identity Provider Settings aus.
  1. Tragen Sie den Anzeigenamen ein, wie z. B. “Mein ADFS-Server”
  2. Was die WS-Verbundmetadaten anbetrifft, tragen Sie einfach die URL für den Endpunkt der Verbundmetadaten ein, wenn Ihr AD FS-Server über das Internet offengelegt wird. Die Standardeinstellung ist: **https://yourAdfsServer.com/FederationMetadata/2007-06/FederationMetadata.xml**. Wenn Ihr ADFS-Server nicht im Internet offengelegt wird, öffnen Sie die URL in Ihrem lokalen Browser am Endpunkt. Wechseln Sie zu Ihrem Browser, und speichern Sie die Seite im lokalen Dateisystem als XML-Datei. Klicken Sie dann in ACS in den Identitätsanbietereinstellungen auf das Optionsfeld neben dem Bearbeitungsfeld File, und suchen Sie mithilfe der Schaltfläche Browse nach der XML-Verbundmetadatendatei, die Sie gerade gespeichert haben.

Mehr ist eigentlich nicht notwendig, um einen Identitätsanbieter in ACS zu erstellen.

3. Fügen Sie eine vertrauende Seite für SharePoint hinzu

1. Jetzt müssen Sie SharePoint als vertrauende Seite von ACS hinzufügen, genau wie bei der gemeinsamen Konfiguration von SharePoint und AD FS. Klicken Sie zunächst im linken Bereich im Menü Trust relationships auf die Verknüpfung Relying party applications.
2. Klicken Sie auf die Verknüpfung Add.
3. Füllen Sie den Abschnitt Relying Party Application Settings aus.
  1. Geben Sie einen Anzeigenamen wie SharePoint 2010 ein.
  2. Verwenden Sie den Standardmodus zur manuellen Eingabe der Einstellungen.
  3. Geben Sie einen Bereich in das Bearbeitungsfeld Realm ein, und speichern Sie ihn, da Sie ihn zu einem späteren Zeitpunkt beim Erstellen von SPTrustedIdentityTokenIssuer in SharePoint erneut benötigen. Im Rahmen dieses Beispiels nehmen wir an, dass der Bereich urn:sharepoint:acs lautet.
  4. Verwenden Sie dasselbe Format für die Rückgabe-URL wie beim Einrichten von SharePoint als vertrauende Seite in AD FS: https://yourSiteName/_trust/.
  5. Im Dropdownfeld Token format sollte SAML 1.1 angezeigt werden.
  6. Sie können Token lifetime (secs) auf eine beliebige Dauer festlegen. Standardmäßig sind 10 Minuten ausgewählt; ich habe den Wert auf 3600, also 1 Stunde, festgelegt.
4. Füllen Sie den Abschnitt Authentication Settings aus.
  1. Überprüfen Sie die Felder für die Identitätsanbieter; es sollte der AD FS-Identitätsanbieter angezeigt werden, den Sie im vorherigen Schritt erstellt haben
  2. Lassen Sie unter Rule groups die Standardeinstellung Create new rule aktiviert.
5. Lassen Sie unter Token Signing Settings die Standardoption Use service namespace certificate (standard) aktiviert.
6. Klicken Sie auf die Schaltfläche Save zum Speichern der Änderungen, und erstellen Sie die vertrauende Seite.

4. Erstellen Sie die Regeln für die vertrauende Seite

1. Ich gehe hier davon aus, dass Sie nicht bereits Regeln in ACS erstellt haben und somit eine neue Regelgruppe erstellt werden muss. Falls Sie über eine Gruppe verfügen, die Sie wiederverwenden möchten, aktivieren Sie einfach im vorherigen Schritt die Grupp(n), die für die vertrauende Seite verwendet werden soll(en), anstatt die Standardeinstellung Create new rule group zu übernehmen. Da hier jedoch eine neue Regelgruppe erstellt werden soll, klicken Sie im linken Bereich im Menü Trust relationships auf die Verknüpfung Rule groups.
2. Es sollte eine Regelgruppe angezeigt werden, deren Name so lautet wie Default Rule Group for whatever your relying party name was”. Klicken Sie auf die Verknüpfung für diesen Regelgruppennamen.
3. Am einfachsten ist es an dieser Stelle, auf die Verknüpfung Generate zu klicken. Es wird dann automatisch eine Gruppe von Regeln erstellt, in der im Wesentlichen alle Ansprüche der einzelnen Identitätsanbieter aufgezählt sind. Dann wird eine Regel für jeden Anspruch erstellt, der den Anspruchwert mit demselben Anspruchstyp an die vertrauende Instanz weitergibt.
4. Aktivieren Sie auf der Seite Generate Rules das Feld neben jedem Identitätsanbieter, und klicken Sie dann auf die Schaltfläche Generate. Dadurch werden die Regeln wie weiter oben beschrieben erstellt. Nach dem Erstellen der Regeln werden Sie zur Seite Edit Rule Group umgeleitet. Dort werden alle Regeln aufgelistet. In vielen Fällen wäre dies ausreichend, doch müssen wir hier eine Unregelmäßigkeit berücksichtigen. In SharePoint verwenden wir die E-Mail-Adresse als Identitätsanspruch. Ironischerweise leiten alle Identitätsanbieter die E-Mail-Adresse weiter (und haben sogar entsprechende Regeln erstellt) mit Ausnahme von Windows Live. Ich werde also in diesem Beispiel den Windows Live-Teil "fälschen". Damit meine ich, dass ich mithilfe des einen Anspruchs, der bereitgestellt wird (nameidentifier) eine Regel erstelle, die den Anspruch jedoch als E-Mail-Anspruch zurückgeben soll. Damit will ich nicht persönlich mit Steve abrechnen, sondern es ist einfach eine Möglichkeit, diese Demoumgebung mit dem geringsten Aufwand ans Laufen zu kriegen. Wir fügen also diese letzte Regel hinzu.
5. Klicken Sie auf die Verknüpfung Add.
6. Wählen Sie im Dropdownfeld Identity Provider die Option Windows Live aus.
7. Klicken Sie im Abschnitt Input claim type auf das Optionsfeld neben Select type: . Es wird nur ein Anspruchstyp von Windows Live ID unterstützt; somit ist dieser bereits ausgewählt (nameidentifier)
8. Führen Sie einen Bildlauf nach unten zum Abschnitt Output claim type aus, und klicken Sie auf das Optionsfeld neben Select type: .
9. Suchen Sie in der Dropdownliste nach https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, und wählen Sie die Option aus.
10. Geben Sie ggf. eine Beschreibung ein, klicken Sie auf die Schaltfläche Save, um die Änderungen zu speichern, und erstellen Sie die Regel.
11. Sie werden zur Seite Edit Rule Group umgeleitet. Klicken Sie dann auf die Schaltfläche Save, um alle Änderungen zu speichern. Sie haben ACS nun vollständig konfiguriert. Schließen Sie den Browser jedoch noch nicht, da Sie beim Erstellen und Konfigurieren der anderen Komponenten noch zusätzliche Informationen daraus benötigen.

5. Erstellen Sie eine vertrauende Seite für ACS in AD FS

1. Während AD FS ein Identitätsanbieter für ACS ist, ist ACS eine vertrauende Seite für AD FS. Das bedeutet, dass wir eine vertrauende Seite in AD FS konfigurieren müssen, damit eine Vertrauensstellung vorhanden ist, die es AD FS ermöglicht zu antworten, wenn ACS eine Authentifizierungsanforderung an AD FS umleitet. Öffnen Sie die Verwaltungskonsole von AD FS 2.0 auf Ihrem AD FS-Server.
2. Öffnen Sie in AD FS 2.0 das Menü Trust Relationships und dann den Knoten Relying Party Trusts. Klicken Sie dann im linken Bereich auf die Verknüpfung Add Relying Party Trust.
3. Klicken Sie auf die Schaltfläche Start, um den Assistenten zu öffnen.
4. Verwenden Sie die Standardoption zum Importieren von Daten über die vertrauende Seite, die online veröffentlicht werden. Die erforderliche URL befindet sich im Verwaltungsportal von ACS. Wechseln Sie zurück zu Ihrem Browser, in dem das Portal geöffnet ist, und klicken Sie im linken Bereich unter dem Menü Trust relationships auf die Verknüpfung Application Integration.
5. Kopieren Sie die URL, die für die WS-Verbundmetadaten angezeigt wird, und fügen Sie sie in das Bearbeitungfeld Federation metadata address (host name or URL): im AD FS-Assistenten ein. Klicken Sie dann auf die Schaltfläche Next.
6. Geben Sie einen Anzeigenamen und optional einige Anmerkungen ein, und klicken Sie dann auf die Schaltfläche Next.
7. Lassen Sie die Standardoption aktiviert, bei der alle Benutzer auf die vertrauende Seite zugreifen dürfen, und klicken Sie dann auf die Schaltfläche Next.
8. Klicken Sie auf die Schaltfläche Next, sodass die vertrauende Seite erstellt wird.
9. Nach dem Erstellen der vertrauenden Seite öffnen Sie den Regel-Editor in AD FS, um neue Regeln für die Übergabe von Anspruchswerten an ACS zu erstellen.
10. Wählen Sie die Registerkarte Issuance Transform Rules aus, und klicken Sie auf die Schaltfläche Add Rule.
11. Lassen Sie die Standardvorlage von Send LDAP Attributes as Claims aktiviert, und klicken Sie auf die Schaltfläche Next.
12. Tragen Sie die restlichen Regeldetails ein:
  1. Geben Sie einen Namen für die Anspruchsregel ein.
  2. Wählen Sie im Dropdownfeld Attribute store die Option Active Directoryaus.
  3. Erstellen Sie im Abschnitt Mapping of LDAP attributes eine Verknüpfung zwischen:
    1. LDAP-Attribut E-Mail-Addresses mit Outgoing Claim Type E-Mail Address
    2. LDAP-Attribut Token-Groups – Unqualified Names mit Outgoing Claim Type Role
  4. Klicken Sie auf die Schaltfläche Finish, um die Regel zu speichern. Die Konfiguration von AD FS ist nun abgeschlossen.

6. Konfigurieren Sie die SharePoint-Vertrauensstellung mithilfe von ACS

1. Dieser Vorgang setzt sich aus mehreren Schritten zusammen, wobei zuerst das Tokensignaturzertifikat von ACS abgerufen wird. Glücklicherweise ist das Zertifikat in der Datei FederationMetadata.xml enthalten, sodass es von dort übernommen und lokal auf dem SharePoint-Server gespeichert werden kann. Öffnen Sie auf dem SharePoint-Server einen Browser und die Verwaltungsseite für Access Control wie oben beschrieben.
2. Klicken Sie im linken Bereich unter dem Menü Trust relationships auf die Verknüpfung Application Integration. Kopieren Sie die URL, die für die WS-Verbundmetadaten angezeigt wird, und fügen Sie sie in den Browser ein. Die Datei ACS FederationMetadata.xml wird im Browser angezeigt.
3. Suchen Sie nach dem Abschnitt, der mit dem folgenden vergleichbar ist (in etwa der zweite Hauptabschnitt auf der Seite):

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

Kopieren Sie die Daten aus dem X509Certificate-Element und fügen Sie sie in den Editor ein. Speichern Sie sie mit der Dateinamenerweiterung CER (Codierung sollte ANSI sein); im Rahmen dieses Beitrags nehmen wir einmal an, dass Sie die Datei C:\AcsTokenSigning.cer nennen. Dies ist das Tokensignaturzertifikat für ACS.

1. Fügen Sie das Tokensignaturzertifikat von ACS der Liste der vertrauenswürdigen Stammzertifizierungsstellen in SharePoint hinzu. Eine entsprechende Beschreibung dieses Vorgangs finden Sie unter https://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx. Alternativ können Sie PowerShell wie folgt zum Hinzufügen verwenden:

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

New-SPTrustedRootAuthority -Name "ACS Token Signing" -Certificate $cert

1. Im nächsten Schritt wird der neue SPTrustedIdentityTokenIssuer erstellt. Diesen Vorgang habe ich an verschiedenen Stellen bereits beschrieben; als Ausgangspunkt können Sie https://blogs.msdn.com/b/sharepoint_de/archive/2010/11/24/durchg-228-ngiges-konfigurieren-von-sharepoint-160-2010-und-ad-160-fs-160-v2.aspx verwenden (führen Sie einfach einen Bildlauf zu den Informationen NACH dem Einrichten von AD FS aus). Folgende Aspekte sollten berücksichtigt werden:
  1. Sowohl name als auch nameidentifier sind reservierte Anspruchstypen in SharePoint, somit ist nameidentifier zwar der einzige gemeinsame Anspruch aller Standardidentitätsanbieter in ACS, ist jedoch dennoch keine Option, als Identitätsanspruch verwendet zu werden. In diesem Fall empfehle ich, auf die E-Mail-Adresse zurückzugreifen und die entsprechenden Regeln in ACS hinzuzufügen, wie oben beschrieben.
  2. Der SignInUrl-Parameter für New-SPTrustedIdentityTokenIssuer sollte auf Ihre ACS-Instanz zeigen (Beispiel: https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation). Sie finden diesen Pfad, wenn Sie sich die in AD FS für ACS eingerichtete vertrauende Seite ansehen. Öffnen Sie das Dialogfeld mit den Eigenschaften der vertrauenden Seite, klicken Sie auf die Registerkarte mit den Endpunkten, und verwenden Sie die URL, die für den WS-Passivverbund-Endpunkt für die POST-Bindung angezeigt wird (es sollte die einzige hier sein).
2. Der letzte Schritt besteht darin, Ihre Webanwendung zu erstellen, die anspruchsbasierte Authentifizierung und den für ACS erstellten SPTrustedIdentityTokenIssuer zu konfigurieren und schließlich eine Websitesammlung in der Webanwendung zu erstellen und mit dem Testen zu beginnen.

Versuchen Sie an dieser Stelle, die Website zu öffnen und mal auzuprobieren. Denken Sie daran, dass Sie den Websitesammlungsadministrator als eine der E-Mail-Adressen konfigurieren müssen, die von einem der Identitätsanbieter zurückgegegeben wird, um sich an der Website anmelden zu können. Nach dem Anmelden können Sie SharePoint-Gruppen E-Mail-Adressen oder Rollenansprüche ganz regulär hinzufügen.

Der einzige Haken ist auch hier wieder die Windows Live ID. Wie weiter oben in diesem Beitrag schon erwähnt, steht Ihnen keine wirklich gültige E-Mail-Adresse für Windows Live zur Verfügung, deshalb müssen Sie das, was als PUID bezeichnet wird, zu Ihrer SharePoint-Gruppe hinzufügen. Zu Testzwecken ist es am einfachsten, sich die PUID zu beschaffen, indem Sie sich über die Windows Live ID anmelden. Sie gelangen dann zu der Seite in SharePoint, die besagt, dass Sie als "foo" angemeldet sind und der Zugriff verweigert wird. Hier können Sie die PUID kopieren; melden Sie sich als Administrator an, fügen Sie die PUID einer SharePoint-Gruppe hinzu, und Sie haben es geschafft. Ich habe mich noch nicht mit den etwaigen Verzeichnisoptionen, die für die Windows Live ID zur Verfügung stehen, beschäftigt (vermutlich gibt es gar keine). Aber immerhin ist das ein Anfang, und wir können mit diesem Nachweis der Wirksamkeit fortfahren. Nachdem wir das getan haben, sehen Sie hier, wie eine Anmeldung an meiner Website über die verschiedenen Identitätsanbieter aussieht:

Anmeldeseite

ADFS

Google

Yahoo

Windows Live ID

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1

Share via

SAML-basierte Verbundauthentifizierung mit SharePoint 2010 und Azure Access Control Service, Teil 1

Additional resources