Planen von benutzerdefinierten Anspruchsanbietern für Personen-Auswahl in SharePoint

GILT FÜR:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

Sie können die Anspruchsanbieter verwenden, die in SharePoint Server enthalten sind, oder Sie können eigene benutzerdefinierte Anspruchsanbieter erstellen, um eine Verbindung mit zusätzlichen Anspruchsquellen herzustellen und zusätzliche Ansprüche im Sicherheitstoken für einen Benutzer bereitzustellen. Wenn Sie z. B. eine CRM-Anwendung mit Rollen verwenden, die sich nicht im Benutzerrepository in den Active Directory-Domänendienste (AD DS) befinden, können Sie einen benutzerdefinierten Anspruchsanbieter erstellen, um eine Verbindung mit der CRM-Datenbank herzustellen und CRM-Rollendaten einem ursprünglichen Sicherheitstoken eines Benutzers hinzuzufügen. Weitere Informationen zu Verwendungsszenarien für Anspruchsanbieter finden Sie unter Anspruchsanbieter.

Ein Anspruchsanbieter in SharePoint Server wird verwendet, um Ansprüche zu erweitern und namensauflösung bereitzustellen. In der Anspruchserweiterungsrolle erweitert ein Anspruchsanbieter ein Benutzersicherheitstoken während der Anmeldung um zusätzliche Ansprüche. Weitere Informationen zur Anspruchserweiterung finden Sie unter Anspruchsanbieter. In der Namensauflösungsrolle dient der Anspruchsanbieter zum Auflisten, Auflösen, Suchen und Bestimmen des Anzeigenamens von Benutzern, Gruppen und Ansprüchen in der Personenauswahl. Die Anspruchsauswahl ermöglicht es einer Anwendung, Ansprüche in der Personenauswahl anzuzeigen (beispielsweise beim Konfigurieren der Sicherheit einer SharePoint-Website oder des SharePoint-Diensts). Weitere Informationen zu Personen-Auswahl finden Sie unter Planen der Personen-Auswahl in SharePoint.

Standardmäßig hängen die Informationen, die in der Personenauswahl beim Ausführen einer Abfrage aufgelöst werden, von den vom Anspruchsanbieter bereitgestellten Informationen ab. Sie können nicht ändern, welche Informationen bereitgestellt werden und wie diese angezeigt werden, wenn Sie die mitgelieferten Anspruchsanbieter verwenden. Hierzu müssen Sie einen benutzerdefinierten Anspruchsanbieter erstellen, der die Bedürfnisse Ihrer Lösung zur Suche und Auswahl von Benutzern, Gruppen und Ansprüchen erfüllt, wenn ein Benutzer Elementen wie einer Website, Liste oder Bibliothek Berechtigungen zuweist.

Wenn Sie einen benutzerdefinierten Anspruchsanbieter erstellen, können Sie die angezeigten Informationen und die als Antwort auf eine Abfrage aus dem Personenauswahl-Steuerelement zurückgegebenen Ergebnisse steuern. Standardmäßig konfigurieren Sie die Webanwendung für die Verwendung der anspruchsbasierten Authentifizierung und registrieren dann den Anspruchsanbieter auf dem Server.

Machen Sie sich vor der Lektüre dieses Artikels nach Möglichkeit mit den unter Planen der Benutzerauthentifizierungsmethoden in SharePoint Server und Die Rolle von Forderungen beschriebenen Konzepten vertraut. Zusätzliche Informationen zur anspruchsbasierten Authentifizierung finden Sie unter Anspruchsbasierte Identität in SharePointsowie unter Handbuch zur forderungsbasierten Identitäts- und Zugriffssteuerung.

Architektur

Wenn eine Webanwendung für die Verwendung der anspruchsbasierten Authentifizierung konfiguriert ist, verwendet SharePoint Server automatisch zwei Standardanspruchsanbieter:

Abhängig von der für eine Zone einer Webanwendung ausgewählten Authentifizierungsmethode verwendet SharePoint Server auch einen oder mehrere der in Tabelle 1 aufgeführten Standardanspruchsanbieter.

Tabelle 1. Authentifizierungsmethoden und Standardanspruchsanbieter

Authentifizierungsmethode Anspruchsanbieter
Windows-Authentifizierung
SPActiveDirectoryClaimProvider
Formularbasierte Authentifizierung
SPFormsClaimProvider
Auf SAML-Token (Security Assertion Markup Language) basierte Authentifizierung
SPTrustedClaimProvider

Sie können eine Liste mit Anspruchsanbietern für eine Farm anzeigen, indem Sie das Microsoft PowerShell-Cmdlet Get-SPClaimProvider verwenden.

Hinweis

[!HINWEIS] Wenn eine Webanwendung für die Verwendung der auf SAML-Token basierten Authentifizierung konfiguriert ist, wird von der SPTrustedClaimProvider-Klasse keine Suchfunktionalität für das Personenauswahl-Websteuerelement zur Verfügung gestellt. Jeder in das Personenauswahl-Steuerelement eingegebene Text wird automatisch angezeigt, als wäre er aufgelöst worden, unabhängig davon, ob es sich um einen gültigen Benutzer, eine gültige Gruppe oder einen gültigen Anspruch handelt. Wenn Ihre SharePoint Server-Lösung die SAML-tokenbasierte Authentifizierung verwendet, sollten Sie planen, einen benutzerdefinierten Anspruchsanbieter zu erstellen, um eine benutzerdefinierte Suche und Namensauflösung zu implementieren.

Anspruchsanbieter werden in einer Serverfarm als Features registriert, die für die Farm bereitgestellt werden. Sie sind auf Farmebene gültig. Jedes Anspruchsanbieterobjekt verwendet die SPClaimProviderDefinition-Klasse, um Informationen zum Anspruchsanbieter einzuschließen, z. B. den Anzeigenamen, die Beschreibung, die Assembly und den Typ. Zwei wichtige Eigenschaften der SPClaimProviderDefinition-Klasse sind IsEnabled und IsUsedByDefault. Diese Eigenschaften bestimmen, ob ein registrierter Anspruchsanbieter für die Verwendung in der Farm aktiviert ist und ob der Anspruchsanbieter standardmäßig in einer bestimmten Zone verwendet wird. Standardmäßig sind alle Anspruchsanbieter aktiviert, wenn sie in einer Serverfarm bereitgestellt werden. Informationen zur SPClaimProviderDefinition-Klasse finden Sie unter SPClaimProviderDefinition .

Weitere Informationen zu Zonen und zur Authentifizierung finden Sie unter Planen der Benutzerauthentifizierungsmethoden in SharePoint Server.

Beispiel für eine benutzerdefinierte Anspruchsanbieterkonfiguration

Standardmäßig werden bei der Registrierung eines benutzerdefinierten Anspruchsanbieters in der Farm die Eigenschaften "IsEnabled" und "IsUsedByDefault" auf "True" festgelegt. Abhängig von der Anzahl der Zonen, die für Ihre SharePoint Server-Lösung erforderlich sind, den Authentifizierungsmethoden, die von jeder Zone verwendet werden, und den Benutzern für jede Zone können Sie die Zonen einschränken, in denen Ihr benutzerdefinierter Anspruchsanbieter in Personen Auswahl angezeigt wird.

Da sich Anspruchsanbieter auf die Farmebene beziehen und auf der Zonenebene aktiviert werden, müssen Sie die Zonen, in denen die benutzerdefinierten Anspruchsanbieter angezeigt werden sollen, sorgfältig planen. Im Allgemeinen sollten Sie sicherstellen, dass die IsUsedByDefault-Eigenschaft auf "False" festgelegt ist und anschließend die SPIisSettings -Klasse für jede Zone konfigurieren, in der der benutzerdefinierte Anspruchsanbieter verwendet werden soll. Um einen benutzerdefinierten Anspruchsanbieter für ausgewählte Zonen zu konfigurieren, können Sie ein PowerShell-Skript erstellen, das den Anspruchsanbieter für eine Zone unter Verwendung der ClaimsProviders() -Eigenschaft festlegt, oder Sie erstellen eine benutzerdefinierte Anwendung, die die Aktivierung eines benutzerdefinierten Anspruchsanbieters für ausgewählte Zonen ermöglicht.

Stellen Sie sich beispielsweise ein Szenario mit zwei Webanwendungen vor:

  • Die erste Webanwendung, PartnerWeb, besitzt zwei Zonen: ein Intranet mit anspruchsbasierter Windows-Authentifizierung und ein Extranet mit formularbasierter Authentifizierung. Dieses Webanwendung wird für die Zusammenarbeit von Mitarbeitern und Partnern genutzt.

  • Die zweite Webanwendung, PublishingWeb, besitzt lediglich eine Zone mit formularbasierter Authentifizierung und fungiert als Internetveröffentlichungswebsite für Mitarbeiter, Geschäftspartner und Kundenpartner.

Nehmen wir nun an, dass es den Mitarbeitern in der Extranetzone von PartnerWeb möglich sein soll, mit Geschäftspartnern zusammenzuarbeiten, nicht jedoch mit Kundenpartnern. Zu diesem Zweck wird ein benutzerdefinierter Anspruchsanbieter erstellt, der anhand der Identität des Benutzers ermittelt, ob der aktuelle Benutzer ein Geschäftspartner oder ein Kundenpartner ist. In diesem Beispiel handelt es sich bei Benutzern von "fabrikam.com" um Geschäftspartner, bei Benutzern von "contoso.com" dagegen um Kundenpartner. Wenn nun ein Geschäftspartnerbenutzer in der PartnerWeb-Webanwendung authentifiziert wird, wird dem Anspruchstoken ein Anspruch für eine Rolle mit dem Namen "BusinessPartner" hinzugefügt. Bei der Authentifizierung eines Kundenpartners wird dem Anspruchstoken dagegen ein Anspruch für eine Rolle mit dem Namen "CustomerPartner" hinzugefügt.

Um sicherzustellen, dass Kundenpartner auf keinen Fall der Website für Zusammenarbeit im Extranet hinzugefügt werden, können Sie in der PartnerWeb-Webanwendung eine Webanwendungsrichtlinie für die Extranetzone hinzufügen, in der einem Benutzer, der einen Anspruch für eine Rolle mit dem Namen "CustomerPartner" besitzt, explizit der Zugriff verweigert wird. Der benutzerdefinierte Anspruchsanbieter muss auch die Suche und die Eingabeunterstützung für die Webanwendungsrichtlinie implementieren, um den Anspruch der Rolle "CustomerPartner" aufzulösen, sodass er der Webanwendungsrichtlinie hinzugefügt werden kann. Abschließend muss zur Aktivierung dieser Funktion in der Extranetzone die SPIisSettings -Klasse für diese Zone konfiguriert werden, damit der benutzerdefiniert Anspruchsanbieter verwendet wird. Das folgende Diagramm zeigt die Authentifizierungsmethoden und Einstellungen für den Anspruchsanbieter für die einzelnen Webanwendungen und Zonen:

Abbildung 1: Beispiel für die Authentifizierungsmethoden und Anspruchsanbietereinstellungen für Webanwendungen und Zonen

SPIisSettings-Diagramm

Sie können die IsUsedByDefault-Eigenschaft festlegen, indem Sie sie in einem Featureempfänger konfigurieren, den Sie für den benutzerdefinierten Anspruchsanbieter erstellen.

Sie können auch die Einstellungen der Eigenschaften IsEnabled und IsUsedByDefault außer Kraft setzen, indem Sie das Set-SPClaimProviderPowerShell-Cmdlet verwenden.

Wichtig

[!WICHTIGER HINWEIS] Beim Ändern der IsEnabled-Eigenschaft auf False wird der Anspruchsanbieter für die Serverfarm deaktiviert. Dies kann bei der Problembehandlung wichtig sein, wenn Probleme durch einen benutzerdefinierten Anspruchsanbieter verursacht sein können. Im Allgemeinen sollte die IsEnabled-Eigenschaft auf True festgelegt sein.

Verwenden von benutzerdefinierten Ansprüchen in mehr als einer Farm

Anspruchswerte sind eine Kombination aus dem Anspruch selbst, dem Namen des Anspruchsanbieters und der Reihenfolge, in der der Anspruchsanbieter auf dem Server installiert wurde. Wenn Sie also einen Anspruch in mehreren Farmen oder Umgebungen verwenden möchten, müssen Sie die Anspruchsanbieter in derselben Reihenfolge in jeder Farm installieren, in der Sie den Anspruch verwenden möchten. Führen Sie die folgenden Schritte aus, wenn Sie einen benutzerdefinierten Anspruchsanbieter in einer Farm installiert haben und denselben Anspruch in weiteren Farmen verwenden möchten.

  1. Registrieren Sie die Anspruchsanbieter in weiteren Farmen in derselben Reihenfolge wie in der ersten Farm.

  2. Sichern Sie die erste Farm. Informationen zum Sichern einer Farm finden Sie unter Sichern von Farmen in SharePoint Server.

  3. Verwenden Sie die Sicherung der ersten Farm zum Wiederherstellen der anderen Farmen. Informationen zum Wiederherstellen einer Farm finden Sie unter Wiederherstellen von Farmen in SharePoint Server.

Überlegungen zur Planung von benutzerdefinierten Anspruchsanbietern

Bei der Planung von benutzerdefinierten Anspruchsanbietern zur Verwendung in der Personenauswahl der SharePoint-Lösung sollten Sie die folgenden Fragen beantworten:

  • Welche Zonen sind in der Webanwendung vorhanden, und welche Authentifizierungsmethoden werden in jeder Zone verwendet?

  • Sind benutzerdefinierte Ansprüche vorhanden, die Benutzern hinzugefügt werden sollten, um erweiterte Berechtigungs- oder Sicherheitsszenarien zu ermöglichen?

  • Wird die SAML-Authentifizierung mit einem vertrauenswürdigen Identitätsanbieter verwendet?

  • Aus welcher Quelle stammen die Werte für die Benutzer und Rollen, die in den Abfrageergebnissen der Personenauswahl angezeigt werden?

Das SharePoint Server Content Publishing-Team möchte Steve Peschka für seine Mitwirkung an diesem Artikel danken. Seinen Blog finden Sie unter Share-n-dipity TechNet blog.

Siehe auch

Konzepte

Übersicht über Personenauswahl und Anspruchsanbieter

Planen der Benutzerauthentifizierungsmethoden in SharePoint Server