Konfigurieren des Sicherheitstokendiensts (SharePoint Server 2010)
Gilt für: SharePoint Foundation 2010, SharePoint Server 2010
Letztes Änderungsdatum des Themas: 2016-11-30
Dieser Artikel enthält Anleitungen zum Konfigurieren des Sicherheitstokendiensts (Security Token Service, STS) von Microsoft SharePoint Server 2010. Bei einem STS handelt es sich um einen speziellen Webdienst, mit dem auf Anforderungen für Sicherheitstoken reagiert und die Identitätsverwaltung ermöglicht wird. Die zentralen Funktionen jedes STS sind identisch, aber die von jedem STS ausgeführten Aufgaben hängen von der Rolle ab, die der STS in Bezug auf Ihre anderen STS-Dienste spielt.
Inhalt dieses Artikels:
Funktionsweise von Webanwendungen, die einen STS verwenden
Konfigurieren einer anspruchsbasierten SharePoint-Webanwendung mithilfe von Windows PowerShell
Bearbeiten von Bindungen
Konfigurieren einer Webanwendung, die einen STS verwendet
Funktionsweise von Webanwendungen, die einen STS verwenden
In Webanwendungen, von denen ein Sicherheitstokendienst (Security Token Service, STS) verwendet wird, werden Anforderungen zum Ausstellen, Verwalten und Überprüfen von Sicherheitstoken verarbeitet. Sicherheitstoken bestehen aus einer Sammlung von Identitätsansprüche (beispielsweise dem Namen eines Benutzers, der Rolle oder einer anonymen ID). Token können in verschiedenen Formaten ausgestellt werden, beispielsweise als SAML-Token (Security Assertion Markup Language). Sicherheitstoken können mit einem X.509-Zertifikat geschützt werden, um den Inhalt des Tokens während der Übertragung zu schützen und die Überprüfung vertrauenswürdiger Aussteller zu ermöglichen. Weitere Informationen zum Sicherheitstokendienst finden Sie unter Planen von Authentifizierungsmethoden (SharePoint Server 2010).
Ein Identitätsanbieter-Sicherheitstokendienst (Identity Provider Security Token Service, IP-STS) ist ein Webdienst, der Anforderungen für vertrauenswürdige Identitätsansprüche behandelt. Ein IP-STS verwendet eine als Identitätsspeicher bezeichnete Datenbank zum Speichern und Verwalten von Identitäten und deren zugeordnete Attribute. Beim Identitätsspeicher für einen Identitätsanbieter kann es sich um eine einfache handeln, wie z. B. eine SQL-Datenbanktabelle. Ein IP-STS kann auch einen komplexen Identitätsspeicher verwenden, wie z. B. Active Directory-Domänendienste (AD DS) oder Active Directory Lightweight Directory Service (AD LDS).
Ein IP-STS ist für Clients verfügbar, die Identitäten erstellen und verwalten möchten, und für Relying Party-Anwendungen (vertrauende Seite), mit denen von den Clients präsentierte Identitäten überprüft werden müssen. Jeder IP-STS verfügt über eine Verbundvertrauensstellung mit bzw. stellt Token für Relying Party-STS-Webanwendungen von Verbundpartnern aus, die jeweils als RP-STS bezeichnet werden. Die Clients können verwaltete Informationskarten (mithilfe eines Kartenselektors wie z. B. CardSpace) erstellen oder bereitstellen, die für den IP-STS registrierte Identitäten darstellen. Die Clients interagieren mit dem IP-STS, wenn sie Sicherheitstoken anfordern, die eine im Identitätsspeicher des IP-STS enthaltene Identität darstellen. Nach der Authentifizierung stellt der IP-STS ein vertrauenswürdiges Sicherheitstoken aus, das der Client einer Relying Party-Anwendung präsentieren kann. Mit Relying Party-Anwendungen können Vertrauensstellungen mit einem IP-STS eingerichtet werden. Auf diese Weise können sie die von einem IP-STS ausgestellten Sicherheitstoken überprüfen. Nachdem die Vertrauensstellung eingerichtet wurde, können mit Relying Party-Anwendungen von Clients präsentierte Sicherheitstoken überprüft werden und die Gültigkeit der darin enthaltenen Identitätsansprüche kann bestimmt werden.
Ein Relying Party-Sicherheitstokendienst (Relying Party Security Token Service, RP-STS) ist ein STS, der Sicherheitstoken von einem vertrauenswürdigen Verbundpartner-IP-STS empfängt. Der RP-STS stellt wiederum neue Sicherheitstoken für eine lokale Relying Party-Anwendung aus. Durch die Verwendung von RP-STS-Webanwendungen im Verbund mit IP-STS-Webanwendungen können Organisationen Benutzern von Partnerorganisationen die einmalige Webanmeldung (Web-SSO) anbieten. Jede Organisation verwaltet weiterhin ihre eigenen Identitätsspeicher.
Konfigurieren einer anspruchsbasierten SharePoint-Webanwendung mithilfe von Windows PowerShell
Führen Sie die folgenden Verfahren aus, um mithilfe von Windows PowerShell eine anspruchsbasierte SharePoint-Webanwendung zu konfigurieren.
So konfigurieren Sie eine anspruchsbasierte SharePoint-Webanwendung mithilfe von Windows PowerShell
Stellen Sie sicher, dass die folgenden Mindestanforderungen erfüllt sind: Weitere Informationen finden Sie unter Add-SPShellAdmin.
Klicken Sie im Startmenü auf Alle Programme.
Klicken Sie auf Microsoft SharePoint 2010-Produkte.
Klicken Sie auf SharePoint 2010-Verwaltungsshell.
Erstellen Sie wie im folgenden Beispiel an der Windows PowerShell-Eingabeaufforderung (PS C:\>) das x509Certificate2-Objekt:
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path to cert file")
Erstellen Sie wie im folgenden Beispiel eine Anspruchszuordnung zur Verwendung in Ihrem Authentifizierungsanbieter:
New-SPClaimTypeMapping "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
Erstellen Sie wie im folgenden Beispiel einen vertrauenswürdigen Anmeldeanbieter, indem Sie zuerst einen Wert für den realm-Parameter erstellen:
$realm = "urn:" + $env:ComputerName + ":domain-int"
Erstellen Sie wie im folgenden Beispiel einen Wert für den
signinurl
-Parameter, der auf die Webanwendung verweist:$signinurl = "https://test-2/FederationPassive/"
Erstellen Sie wie im folgenden Beispiel den vertrauenswürdigen Anmeldeanbieter, und verwenden Sie dabei denselben
IdentifierClaim
-Wert wie für eine Anspruchszuordnung ($map1.InputClaimType
):$ap = New-SPTrustedIdentityTokenIssuer -Name "WIF" -Description "Windows® Identity Foundation" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1[,$map2..] -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
Erstellen Sie wie im folgenden Beispiel eine Webanwendung, indem Sie zuerst einen Wert für das Anwendungspoolkonto (für den aktuellen Benutzer) erstellen:
$account = "DOMAIN\" + $env:UserName
Hinweis
Das Anwendungspoolkonto muss ein verwaltetes Konto sein. Verwenden Sie
New-SPManagedAccount
zum Erstellen eines verwalteten Kontos.Erstellen Sie wie im folgenden Beispiel einen Wert für die Webanwendungs-URL (
$webappurl = "https://" + $env:ComputerName
):$wa = New-SPWebApplication -name "Claims WIF" -SecureSocketsLayer -ApplicationPool "SharePoint SSL" -ApplicationPoolAccount $account -Url $webappurl -Port 443 -AuthenticationProvider $ap
Erstellen Sie wie im folgenden Beispiel eine Website, indem Sie zuerst ein Anspruchsobjekt erstellen:
$claim = New-SPClaimsPrincipal -TrustedIdentityTokenIssuerr $ap -Identity $env:UserName
Erstellen Sie wie im folgenden Beispiel eine Website:
$site = New-SPSite $webappurl -OwnerAlias $claim.ToEncodedString() -template "STS#0"
Bearbeiten von Bindungen
Nachdem Sie eine anspruchsbasierte SharePoint-Webanwendung erstellt haben, bearbeiten Sie die Bindungen.
So bearbeiten Sie Bindungen
Starten Sie den IIS-Manager, indem Sie INETMGR an einer Eingabeaufforderung eingeben.
Wechseln Sie zur Website Claims Web Application in IIS.
Klicken Sie im linken Fensterbereich mit der rechten Maustaste auf Claims Web Application, und wählen Sie Bindungen bearbeiten aus.
Wählen Sie https aus, und klicken Sie auf Bearbeiten.
Wählen Sie unter SSL-Zertifikat eines der aufgelisteten Zertifikate aus.
Konfigurieren einer Webanwendung, die einen STS verwendet
Nachdem Sie eine anspruchsbasierte SharePoint Server 2010-Webanwendung konfiguriert, die Bindungen bearbeitet und die Datei Web.Config konfiguriert haben, können Sie anhand des Verfahrens in diesem Abschnitt eine Sicherheitstokendienst-Webanwendung konfigurieren.
So konfigurieren Sie eine Webanwendung, die einen STS verwendet
Öffnen Sie die Verwaltungskonsole von Active Directory-Verbunddienste (AD FS) 2.0.
Erweitern Sie im linken Bereich Policy, und wählen Sie Relying Parties aus.
Klicken Sie im rechten Bereich auf Add Relying Party. Dadurch wird der Konfigurations-Assistent von Active Directory-Verbunddienste (AD FS) 2.0 geöffnet.
Klicken Sie auf der ersten Seite des Assistenten auf Start.
Klicken Sie auf Konfiguration der vertrauenden Seite manuell eingeben und dann auf Weiter.
Geben Sie den Namen einer vertrauenden Seite ein, und klicken Sie auf Weiter.
Stellen Sie sicher, dass Active Directory Federation Services (AD FS) 2.0 Server Profile ausgewählt ist, und klicken Sie auf Weiter.
Klicken Sie auf Weiter, wenn Sie nicht vorhaben, ein Verschlüsselungszertifikat zu verwenden.
Wählen Sie Enable support for Web-browser-based identity federation aus.
Geben Sie den Namen der Webanwendungs-URL ein, und fügen Sie /_trust/ an (z. B. https://servername/_trust/). Klicken Sie auf Weiter.
Geben Sie einen Bezeichner ein, und klicken Sie auf Hinzufügen. Klicken Sie anschließend auf Weiter.
Klicken Sie auf der Zusammenfassungsseite auf Weiter, und klicken Sie dann auf Schließen. Dadurch wird die Regel-Editor-Verwaltungskonsole geöffnet. Konfigurieren Sie mithilfe dieser Konsole die Zuordnung von Ansprüchen von einer LDAP-Webanwendung zu SharePoint.
Erweitern Sie im linken Bereich Neue Regel, und wählen Sie Predefined Rule aus.
Wählen Sie Create Claims from LDAP Attribute Store aus.
Wählen Sie im rechten Bereich in der Dropdownliste Attribute Store den Eintrag Enterprise Active Directory User Account Store aus.
Wählen Sie unter LDAP-Attribut den Eintrag sAMAccountName aus.
Wählen Sie unter Typ des ausgehenden Anspruchs den Eintrag E-Mail-Adresse aus.
Klicken Sie im linken Bereich auf Speichern.