Verwenden von SAML-Ansprüchen in SharePoint 2010 mit Hostheader-Websites

  • Article

Veröffentlichung des Originalartikels: 19.06.2011

Vor kurzem stellte mir jemand die interessante Frage, ob in SharePoint 2010 SAML-Ansprüche mit Hostheader-Websites verwendet werden können. Mein erster Gedanke war "Ja", doch ich forschte etwas nach, um es genauer herauszufinden. Die Antwort bleibt immer noch "Ja", doch die Situation ist nicht so einfach, wie ich gehofft hatte. Als kleines Beispiel erstellte ich eine Webanwendung unter https://hh.vbtoys.com und zwei Hostheader-Websites: https://ash.vbtoys.com und https://josh.vbtoys.com Wenngleich dies nicht gänzlich dem klassischen Modell von Hostheader-Websites (d. h. Vanity-URLs) entspricht, ist zu beachten, dass eine der Einschränkungen bei SAML-Ansprüchen und SharePoint darin besteht, dass Websites SSL verwenden müssen. Anstatt sich mit dem Erstellen eines SSL-Zertifikats mit alternativen Antragstellernamen abzumühen, entschloss ich mich der Einfachheit halber zum Verwenden eines Platzhalterzertifikats. Dies reicht aus, um nachzuweisen, ob alles funktioniert und welche Konfiguration benötigt wird, ist aber auch hoffentlich eine gute Erinnerung an etwas, über das nachgedacht werden sollte, wenn Hostheader-Websites und die SAML-Authentifizierung verwendet werden sollen.

Zunächst führte ich einen einfachen Test durch, um das "utopische" Szenario auszuprobieren, bei dem ich nur eine Konfigurationsänderung vornehmen würde und alle Hostheader-Websites funktionieren würden. Hierfür führte ich zwei Aktionen aus:

  1. Ich erstellte in AD FS (Active Directory-Verbunddienste) eine neue vertrauende Seite, die https://hh.vbtoys.com/_trust/ als WS Federation-Endpunkt und den URN urn:sharepoint:hh verwendete.
  2. Meinem vorhandenen SPTrustedIdentityTokenIssuer-Objekt fügte ich wie folgt einen Anbieterbereich hinzu:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://hh.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:hh")
$ap.Update()

Dann versuchte ich zunächst, https://hh.vbtoys.com zu besuchen, und gelangte ohne Schwierigkeiten auf die Website. Als Nächstes besuchte ich in einem realen Test des utopischen Szenarios https://ash.vbtoys.com. Leider war es nicht utopisch, denn ich wurde letztlich zu einem gänzlich anderen SPTrustedIdentityTokenIssuer-Objekt umgeleitet. Deshalb vermute ich, dass SharePoint seine Liste mit Anbieterbereichen untersucht hat und für https://ash.vbtoys.com nichts fand, weshalb das erste SPTrustedIdentityTokenIssuer-Objekt in meiner Liste verwendet wurde.

Doch es war noch nicht alles verloren. Wie Sie sich an dieser Stelle bestimmt vorstellen können, konnte ich meine beiden Hostheader-Websites in Betrieb nehmen, doch ich musste Folgendes erstellen:

  1. Eine neue vertrauende Seite in AD FS für jede Hostheader-Websitesammlung
  2. Einen neuen Anbieterbereich für jede Hostheader-Websitesammlung, der dem SPTrustedIdentityTokenIssuer-Objekt hinzugefügt wurde. Ich verwendete exakt denselben oben gezeigten PowerShell-Befehl, bei dem ich nur jeweils die URL und den URN geändert habe. Nun folgt ein Beispiel, wie ich Unterstützung für https://ash.vbtoys.com hinzugefügt habe:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://ash.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:ash")
$ap.Update()

Das Ergebnis ist, dass ich durch Hinzufügen einer neuen vertrauenden Seite und eines neuen Anbieterbereichs (URI und URN) für jede Hostheader-Websitesammlung mich bei jeder Website mithilfe der SAML-Authentifizierung anmelden konnte.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Using SAML Claims in SharePoint 2010 with Host Header Sites