Exemplarische Vorgehensweise zu Ansprüchen: Schreiben von Anspruchsanbietern für SharePoint 2010

Zusammenfassung:  Hier erfahren Sie, wie Sie einen Anspruchsanbieter für die Erweiterung von Ansprüchen und die Bereitstellung von Namensauflösung schreiben. Mithilfe der Anspruchsauthentifizierung können Sie Rechte auf der Grundlage von Ansprüchen zuweisen, ohne zu wissen, wer ein Benutzer ist oder wie er sich authentifiziert. Ihnen müssen lediglich die Attribute des Benutzers bekannt sein.

Letzte Änderung: Donnerstag, 31. Mai 2012

Gilt für: Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Inhalt dieses Artikels
Übersicht über Anspruchsanbieter
Teil 1: Erweitern der Ansprüche und Registrieren des Anbieters
Teil 2: Hinzufügen der Unterstützung von Hierarchieknoten
Teil 3: Suchen nach Ansprüchen
Teil 4: Unterstützung der Namensauflösung
Schlussbemerkung
Weitere Ressourcen

Bereitgestellt von:  Steve Peschka, Microsoft Corporation

Inhalt

• Übersicht über Anspruchsanbieter

• Teil 1: Erweitern der Ansprüche und Registrieren des Anbieters

• Teil 2: Hinzufügen der Unterstützung von Hierarchieknoten

• Teil 3: Suchen nach Ansprüchen

• Teil 4: Unterstützung der Namensauflösung

• Schlussbemerkung

• Weitere Ressourcen

  Code zum Herunterladen: SqlClaimsProvider_MSDNExample.zip

Übersicht über Anspruchsanbieter

Ein Forderungsanbieter in Microsoft SharePoint 2010 gibt Ansprüche heraus und packt diese in Sicherheitstoken, d. h. in das Token des Benutzers. Wenn sich ein Benutzer bei Microsoft SharePoint Foundation 2010 oder Microsoft SharePoint Server 2010 anmeldet, wird das Token des Benutzers überprüft und anschließend für die Anmeldung bei SharePoint verwendet.

Ein Forderungsanbieter in SharePoint 2010 wird hauptsächlich aus zwei Gründen verwendet:

• Erweitern von Ansprüchen

• Bereitstellen von Namensauflösung

Die Anspruchserweiterung ist Teil eines Vorgangs, der nach Ihrer Anmeldung bei einer Website mit Anspruchsauthentifizierung ausgeführt wird. Es ist wichtig, nicht zu vergessen, dass Folgendes mit der Anspruchsauthentifizierung in SharePoint 2010 ausgeführt werden kann:

• Windows-Ansprüche (bei der Anmeldung mit NTLM oder dem Kerberos-Protokoll)

• Formularbasierte Authentifizierungsansprüche (bei der Verwendung einer ASP.NET-Mitgliedschaft und eines entsprechenden Rollenanbieters)

• SAML (Security Assertions Markup Language)-Ansprüche (bei der Anmeldung über einen Sicherheitstokendienst (STS), z. B. Active Directory-Verbunddienste (AD FS) 2.0)

Nach der Anmeldung werden sämtliche registrierten Anspruchsanbieter für die Webanwendung ausgelöst. Dabei können von den Anspruchsanbietern Ansprüche hinzugefügt werden, die zum Zeitpunkt der Anmeldung nicht angegeben wurden. Nehmen wir zum Beispiel an, Sie haben sich über die Windows-Authentifizierung angemeldet. Es soll jedoch ein zusätzlicher Anspruch gewährt werden, der für den Zugriff auf ein SAP-System verwendet werden kann. Hier kommt die Anspruchserweiterung ins Spiel.

Die Namensauflösung besteht aus zwei Teilen: dem Personenauswahl-Steuerelement und dem Eingabesteuerelement. Wenn Sie möchten, dass Benutzer nach Ansprüchen suchen und Ihre Ansprüche finden können, ist dies mit einem Forderungsanbieter bei Verwendung der Personenauswahl möglich. Mit dem Eingabesteuerelement können Sie einen Benutzernamen oder einen Anspruch eingeben und dann auf die Schaltfläche zum Auflösen klicken. Der Forderungsanbieter kann die Eingabe überprüfen und bestimmen, ob sie gültig ist. Falls die Eingabe gültig ist, führt der Forderungsanbieter die "beste Aktion" aus, um sie aufzulösen.

Nachdem wir nun in abstrakten Begriffen geklärt haben, welche Aktionen mit einem Forderungsanbieter ausgeführt werden können, gehen wir zu dem Szenario über, mit dem wir einen benutzerdefinierten Forderungsanbieter erstellen. In diesem speziellen Szenario möchten wir unserer Websitesammlung auf Grundlage des Lieblingsbasketball-Teams einer Person Rechte hinzufügen. Dies ist eine der tollen Funktionen der Anspruchsauthentifizierung, mit der Sie sich vertraut machen müssen: Es ist nicht wichtig, wer ein Benutzer ist oder wie er sich bei einer Website authentifiziert. Für uns ist nur ein Attribut des Benutzers von Bedeutung, und das ist sein Lieblingsteam.

Für unsere Webanwendung habe ich Windows-Ansprüche und die formularbasierte Authentifizierung aktiviert. Ich nutze die Standard-SQL-Mitgliedschaft und den SQL-Rollenanbieter für die Benutzer mit formularbasierter Authentifizierung und habe meine Liste der formularbasierten Authentifizierungskonten bereits mit user1 bis user50 vorausgefüllt. Um das Szenario zu vereinfachen, wird das Lieblingsteam des Benutzers folgendermaßen bestimmt:

• Das Lieblingsteam aller Windows-Benutzer ist Consolidated Messenger.

• Für die Benutzer mit formularbasierter Authentifizierung gilt:

  • Das Lieblingsteam von user1 bis user15 ist Consolidated Messenger.

  • Das Lieblingsteam von user16 bis user30 ist Wingtip Toys.

  • Das Lieblingsteam von user31 bis user50 ist Tailspin Toys.

Teil 1: Erweitern der Ansprüche und Registrieren des Anbieters

Zuerst wenden wir uns der Anspruchserweiterung zu. Wie bereits beschrieben, löst der Anspruchsanbieter aus, nachdem eine Person authentifiziert wurde. Wir verwenden die zuvor definierten Regeln, um dem Benutzertoken einen Anspruch (welches Team das Lieblingsbasketball-Team ist) hinzuzufügen.

Gehen Sie wie nachfolgend beschrieben vor, um einen Anspruchsanbieter zu schreiben. Im Beispiel wird die Klassenbibliotheksanwendung mit Microsoft Visual Studio 2010 erstellt.

Schritt 1: Hinzufügen von Verweisen

Fügen Sie zuerst Verweise auf Microsoft.SharePoint und Microsoft.IdentityModel hinzu. Normalerweise sollten Sie die Datei Microsoft.SharePoint.dll problemlos in Ihrer SharePoint-Installation finden können. Microsoft.IdentityModel.dll wird mit Windows Identity Foundation installiert. Der vollständige Pfad von Microsoft.IdentityModel.dll in meiner Installation lautet:

<drive>:\Program Files\Reference Assemblies\Microsoft\Windows Identity Foundation\v3.5\Microsoft.IdentityModel.dll

Schritt 2: Hinzufügen von using-Anweisungen und Klassenvererbung

Nachdem die Verweise fertiggestellt sind, müssen wir die using-Anweisungen hinzufügen und die Basisklasse definieren, von der die Klasse erbt. In diesem Beispiel verwenden wir folgende using-Anweisungen.

using Microsoft.SharePoint.Diagnostics;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint.Administration.Claims;
using Microsoft.SharePoint.WebControls;

Die Klasse muss von der SPClaimProvider-Basisklasse erben. Der folgende Code zeigt, wie die Klasse zu Beginn dargestellt wird. Lassen Sie sich nicht durch den Namen SqlClaimsProvider verwirren; ich hatte zuerst vor, den Code nur für die Verwendung der SQL-Mitgliedschaft und des SQL-Rollenanbieters zu schreiben und beschloss später, ihn auch auf Windows anzupassen.

namespace SqlClaimsProvider
{
    public class SqlClaims : SPClaimProvider
    {

        public SqlClaims(string displayName)
            : base(displayName)
        {
        }
    }
}

Schritt 3: Hinzufügen der erforderlichen Implementierung

Es ist nicht nötig, sämtliche Schnittstellen, die Sie implementieren müssen, einzeln durchzugehen. Stattdessen können Sie auf den SPClaimProvider-Namen im vorhergehenden Code zeigen, auf den Dropdownpfeil zeigen, der unter S angezeigt wird, und den Befehl Abstrakte SPClaimProvider-Klasse implementieren auswählen.

Schritt 4: Implementieren der Funktionalität des Anbieters

Nach der Implementierung der abstrakten Klasse müssen Sie unabhängig davon, welche Aktion Sie ausführen möchten, fünf Eigenschaften in die SPClaimProvider-Klasse implementieren: Name, SupportsEntityInformation, SupportsHierarchy, SupportsResolve und SupportsSearch.

Beginnen Sie mit den Supports*-Eigenschaften. Wenn Sie nur eine Anspruchserweiterung ausführen möchten, müssen nur Entitätsinformationen unterstützt werden. Die Eigenschaftenliste in meiner Klasse sieht etwa folgendermaßen aus:

public override bool SupportsEntityInformation
{
      get 
      { 
            return true; 
      }
}

public override bool SupportsHierarchy
{
      get 
      { 
            return false; 
      }
}

public override bool SupportsResolve
{
      get 
      { 
            return false; 
      }
}

public override bool SupportsSearch
{
      get 
      { 
            return false; 
      }
}

Implementieren Sie dann die Unterstützung für die Name-Eigenschaft. Normalerweise sollen sowohl ein Anzeigename als auch ein "interner" Name, mit dem der Anbieter referenziert werden kann, unterstützt werden.

In diesem Fall verwende ich interne statische Eigenschaften, damit ich diese auch mit einer anderen Klasse verwenden kann, die ich an späterer Stelle im Projekt hinzufüge. Meine Implementierung für die Name-Eigenschaft sieht in etwa wie im Folgenden dargestellt aus.

internal static string ProviderDisplayName
{
      get
      {
            return "Basketball Teams";
      }
}


internal static string ProviderInternalName
{
      get
      {
            return "BasketballTeamProvider";
      }
}


public override string Name
{
      get
      {
            return ProviderInternalName;
      }
}

Die grundsätzlichen Implementierungsaufgaben sind damit abgeschlossen. Damit können wir zu interessanteren Dingen übergehen. Ich habe zunächst ein Array zur Verwendung in unserem Forderungsanbieter für die Teams eingerichtet. Es wird wie im Folgenden dargestellt zu Beginn der Klasse hinzugefügt.

// Teams that we are using.
private string[] ourTeams = new string[] { "Consolidated Messenger", "Wingtip Toys", "Tailspin Toys " };

Im folgenden Schritt müssen wir das Herzstück unseres Forderungsanbieters implementieren. Für die Anspruchserweiterung fügen wir Implementierungscode für die FillClaimsForEntity-Methode, die FillClaimTypes-Methode und die FillClaimValueTypes-Methode in der SPClaimProvider-Klasse hinzu.

Zu Beginn erstellen wir einige einfache Hilfsfunktionen, die wir während der Erstellung unseres Forderungsanbieters aufrufen. Diese Hilfsfunktionen definieren den ClaimType (der Anspruchsnamespace oder -bezeichner) und den ClaimValueType (z. B. string oder int).

Folgende zwei Hilfsfunktionen übernehmen diese Aufgabe.

private static string SqlClaimType
{
      get
      {
            return "http://schema.steve.local/teams";
      }
}

private static string SqlClaimValueType
{
      get
      {
            return Microsoft.IdentityModel.Claims.ClaimValueTypes.String;
      }
}

Jetzt können Sie bestimmen, ob der Anspruchsanbieter funktioniert. Falls ja, fügen wir einen Anspruch mit dem Namen http://schema.steve.local/teams und einem string-Wert hinzu.

Aus dem vorstehenden Code und den zugehörigen Informationen können wir ablesen, dass der Wert Consolidated Messenger, Wingtip Toys oder Tailspin Toys ist. Es gibt keine Regeln, wie der Name des Anspruchs auszusehen hat. Normalerweise wenden wir das Format schemas.SomeCompanyName.com/ClaimName an. In diesem Fall ist meine Domäne steve.local. Deshalb habe ich schemas.steve.local ausgewählt. teams ist die Eigenschaft, die mit dem Anspruch nachverfolgt werden soll.

Jetzt kommt der Schritt, in dem der Anspruch selbst hinzugefügt wird. Dies geschieht in der FillClaimsForEntity-Methode der SPClaimProvider-Klasse, wie im folgenden Code dargestellt.

protected override void FillClaimsForEntity(Uri context, SPClaim entity, 
      List<SPClaim> claims)
{
if (entity == null)
      throw new ArgumentNullException("entity");

if (claims == null)
      throw new ArgumentNullException("claims");

// Determine who the user is, so that we know what team to add to their claim
// entity. The value from the input parameter contains the name of the 
// authenticated user. For a SQL forms-based authentication user, it looks similar to
// 0#.f|sqlmembership|user1; for a Windows claims user it looks similar 
// to 0#.w|steve\\wilmaf.
// I will skip some uninteresting code here, to look at that name and determine
// whether it is a forms-based authentication user or a Windows user, and if it is a forms-based authentication user, 
// determine what the number part of the name is that follows "user".

string team = string.Empty;
int userID = 0;
            
// After the uninteresting code, "userID" will equal -1 if it is a Windows user.
// If it is a forms-based authentication user, it will contain the number that follows "user".
            
// Determine what the user's favorite team is.
if (userID > 0)
{
      // Plug in the appropriate team.
      if (userID > 30)
            team = ourTeams[2];
      else if (userID > 15)
            team = ourTeams[1];
      else
            team = ourTeams[0];
}
else
      team = ourTeams[1];  
      // If they are not one of our forms-based authentication users, 
      // make their favorite team Wingtip Toys.
      
// Add the claim.
claims.Add(CreateClaim(SqlClaimType, team, SqlClaimValueType));
}

Besonders wichtig zu erwähnen ist bei dieser Methode die letzte Codezeile. Wir nehmen den claims-Eingabeparameter, der aus einer Liste von SPClaim-Objekten besteht. Wir erstellen mit der CreateClaim-Hilfsmethode einen neuen Anspruch.

Tipp
Es empfiehlt sich, hier nach Möglichkeit immer die Hilfsmethoden zu verwenden. Ihre Funktion umfasst normalerweise mehr als nur die Verwendung der Standardkonstruktoren, und Sie werden in den meisten Fällen feststellen, dass die Abläufe besser funktionieren, wenn die Hilfsmethoden eingesetzt werden.

Zuletzt erstellen wir den Anspruch mit den zwei zuvor beschriebenen Hilfsmethoden: der SqlClaimType-Methode und der SqlClaimValueType-Methode.

Nachdem wir nun den komplexesten Teil des Codes abgeschlossen haben, müssen wir eine Implementierung für zwei weitere Methoden bereitstellen: FillClaimTypes und FillClaimValueTypes. Diese Methoden sind einfach, da wir lediglich unsere Hilfsmethoden dafür verwenden. Die Implementierung sieht in etwa folgendermaßen aus.

protected override void FillClaimTypes(List<string> claimTypes)
{
      if (claimTypes == null)
            throw new ArgumentNullException("claimTypes");

      // Add our claim type.
      claimTypes.Add(SqlClaimType);
}

protected override void FillClaimValueTypes(List<string> claimValueTypes)
{
      if (claimValueTypes == null)
            throw new ArgumentNullException("claimValueTypes");

      // Add our claim value type.
      claimValueTypes.Add(SqlClaimValueType);
}

Das müsste meiner Meinung nach einfach nachvollziehbar sein. Deshalb gehe ich an dieser Stelle nicht mehr weiter darauf ein.

Damit haben wir die grundlegende Implementierung eines Forderungsanbieters, der die Anspruchserweiterung für uns durchführt, abgeschlossen. Wie setzen wir ihn nun ein? Die bevorzugte Methode ist die Verwendung eines Featureempfängers für Ansprüche.

Schritt 5: Erstellen des Featureempfängers für den Anspruchsanbieter

In diesem Schritt beginnen wir damit, dem Projekt eine Klasse hinzuzufügen. Die Klasse erbt von der SPClaimProviderFeatureReceiver-Basisklasse. Die Implementierung ist an sich einfach. Deshalb habe ich den gesamten Code für diesen Teil aus der Beispielcodedatei im folgenden Beispiel kopiert.

using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint.Administration.Claims;
using Microsoft.SharePoint.Diagnostics;


namespace SqlClaimsProvider
{
    public class SqlClaimsReceiver : SPClaimProviderFeatureReceiver
    {

        private void 
              ExecBaseFeatureActivated(
              Microsoft.SharePoint.SPFeatureReceiverProperties properties)
        {
            // Wrapper function for base FeatureActivated. Used because base
            // keyword can lead to unverifiable code inside lambda expression.
            base.FeatureActivated(properties);
        }

        public override string ClaimProviderAssembly
        {
            get 
            {
                return typeof(SqlClaims).Assembly.FullName;
            }
        }

        public override string ClaimProviderDescription
        {
            get 
            { 
                return "A sample provider written by Steve Peschka"; 
            }
        }

        public override string ClaimProviderDisplayName
        {
            get 
            {
                  // This is where we reuse that internal static property.
                return SqlClaims.ProviderDisplayName; 
            }
        }

        public override string ClaimProviderType
        {
            get 
            {
                return typeof(SqlClaims).FullName; 
            }
        }

        public override void FeatureActivated(
              SPFeatureReceiverProperties properties)
        {
            ExecBaseFeatureActivated(properties);
        }
    }
}

Dabei möchte ich noch auf folgende Punkte hinweisen:

• Die ClaimProviderAssembly-Eigenschaft und die ClaimProviderType-Eigenschaft der SPClaimProviderFeatureReceiver-Klasse verwenden ausschließlich Typeigenschaften der benutzerdefinierten Forderungsanbieter-Klasse, die wir geschrieben haben.

• ClaimProviderDisplayName verwendet die interne statische Eigenschaft, die wir für die Forderungsanbieter-Klasse erstellt haben. Wir haben die Eigenschaft so erstellt, dass sie auch im Featureempfänger für Ansprüche verwendet werden kann.

• Das FeatureActivated-Ereignis ruft unsere spezielle interne Methode zur Aktivierung von Eigenschaften auf.

Schritt 6: Kompilieren der Assembly und Hinzufügen zum globalen Assemblycache

Diesen Schritt führe ich manuell durch. Wenn Sie möchten, können Sie dafür jedoch auch ein Lösungspaket verwenden. In diesem Szenario führe ich alle Aufgaben im Entwicklungsmodus auf einem Server durch. Deshalb gehe ich leicht anders vor, da ich noch nicht für die Verteilung auf meiner Farm bereit bin.

Stellen Sie zuerst sicher, dass die Assembly einen starken Namen aufweist, und kompilieren Sie sie dann. Verwenden Sie für das Hinzufügen der Assembly zum globalen Assemblycache eine beliebige Methode. (Ich verwende dazu ein Postbuildereignis und das Tool für den globalen Assemblycache gacutil.exe.) Jetzt können wir die Funktion erstellen und bereitstellen.

Schritt 7: Erstellen und Bereitstellen der Anspruchsanbieterfunktion

In diesem Schritt gibt es nichts besonderes zu Anspruchsanbietern hinzuzufügen. Wir erstellen eine SharePoint-Standardfunktion und stellen sie bereit. Die Grundlagen der Erstellung und Bereitstellung einer Forderungsanbieter-Funktion können in diesem Artikel nicht behandelt werden. Folgende XML-Daten werden aus der Datei feature.xml kopiert, damit Sie einen Eindruck davon erhalten.

Hinweis
Weitere Informationen zum Installieren und Deinstallieren von Funktionen finden Sie unter Installieren oder Deinstallieren von Features.

<Feature   Id="3E864B5C-D855-43e4-B41A-6E054C6C0352" 
           Title="Sql Claims Provider Feature" 
           Scope="Farm" 
           ReceiverAssembly="SqlClaimsProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=eaf1ba21464322ae" 
           ReceiverClass="SqlClaimsProvider.SqlClaimsReceiver" 
           xmlns="https://schemas.microsoft.com/sharepoint/" />

Mithilfe der Datei feature.xml als Referenz habe ich ein Verzeichnis namens SqlClaimsProvider im Ordner Features erstellt und die Funktion installiert. Da es sich um eine Funktion für den Farmbereich handelt, ist sie automatisch aktiviert. Mit dem folgenden Befehl führen Sie diese Aufgabe in Windows PowerShell durch.

install-spfeature -path SqlClaimsProvider

Jetzt sind alle Teile fertig und wir können den Anspruchsanbieter testen.

Schritt 8: Anmelden bei der Website und Testen

Für diesen letzten Schritt verwende ich die Webanwendung, die ich zu Beginn des Artikels beschrieben habe. Sie unterstützt Windows-Ansprüche und formularbasierte Authentifizierungsansprüche.

Hinweis
Weitere Informationen zum Anmelden bei SharePoint finden Sie unter Eingehende Ansprüche: Anmelden bei SharePoint.

Um zu überprüfen, ob meine Ansprüche richtig erweitert werden, habe ich ein Webpart erstellt, das alle meine Ansprüche anzeigt. Ich zeige Ihnen Bildschirmfotos davon, um sicherzustellen, dass die Anspruchserweiterung auch tatsächlich funktioniert.

Zuerst melde ich mich mit meinen Windows-Anmeldeinformationen bei der Website an. Denken Sie daran, dass gemäß dem bereits besprochenen Code einem Windows-Benutzer immer Wingtip Toys als Lieblingsteam zugewiesen sein sollte. In Abbildung 1 wird dargestellt, wie sich dies für den Windows-Benutzer darstellt.

Abbildung 1. Anspruchserweiterung für Windows-Benutzer

In Abbildung 2 erkennen Sie, wie dies bei einem Benutzer mit formularbasierter Authentifizierung aussieht.

Abbildung 2. Anspruchserweiterung für Benutzer mit formularbasierter Authentifizierung

Okay, perfekt – die Anspruchserweiterung funktioniert. In Teil 2 gebe ich eine erste Einführung in die Arbeit mit der Personenauswahl und erkläre, wie eine Hierarchie in der Personenauswahl unterstützt und hinzugefügt wird.

Teil 2: Hinzufügen der Unterstützung von Hierarchieknoten

In Teil 1: Erweitern der Ansprüche und Registrieren des Anbieters habe ich demonstriert, wie ein benutzerdefinierter Forderungsanbieter erstellt und eine Anspruchserweiterung erreicht wird. In Teil 2 zeige ich Ihnen, wie Sie auf einfache Weise eine Hierarchie zum Personenauswahl-Steuerelement hinzufügen können. An sich ist dies nicht unbedingt interessant. In Teil 3 erfahren Sie jedoch, was Sie damit machen können.

Wir kommen zunächst auf die Klasse zurück, die wir für Teil 1 erstellt haben, und befassen und mit einer Eigenschaft und einer Methode der SPClaimProvider-Klasse: der SupportsHierarchy-Eigenschaft und der FillHierarchy-Methode.

Wir streben an, dass die SupportsHierarchy-Eigenschaft true zurückgibt, damit SharePoint erkennt, dass wir eine Hierarchie auffüllen können. Dies wird im folgenden Codeausschnitt demonstriert.

public override bool SupportsHierarchy
{
      get 
      { 
            return true; 
      }
}

Nachdem wir für die SupportsHierarchy-Eigenschaft true festgelegt haben, wird die FillHierarchy-Methode von SharePoint aufgerufen, wenn die Personenauswahl angezeigt wird.

Beim Hinzufügen eines Knotens zur Hierarchie müssen wir einen Anzeigenamen und einen Knotenbezeichner (ID) angeben. Damit dies einfach gehandhabt werden kann und den Lieblingsbasketball-Teams, die wir verwendet haben, entspricht, habe ich einige einfache Hilfsarrays zum Nachverfolgen von Bezeichnungsnamen und -IDs erstellt. Im Folgenden sehen Sie, wie der Code dazu aussieht. Ich zeige außerdem das Array mit Teamnamen, das wir für die Lieblingsteams verwenden.

// Teams that we are using.
private string[] ourTeams = new string[] { "Consolidated Messenger", "Wingtip Toys", "Tailspin Toys " };

// Keys for our People Picker hierarchy.
private string[] teamKeys = new string[] { "empUS", "empEMEA", "empASIA" };

// Labels for our nodes in the People Picker.
private string[] teamLabels = new string[] { "US Teams", "European Teams", "Asian Teams" };

Nachdem wir nun die Schlüssel und Bezeichnungen kennen, sehen wir uns die FillHierarchy-Methode an, mit der die Knoten hinzugefügt werden, wenn das Auswahltool geöffnet wird. Dies dient nur zu Demonstrationszwecken – es gibt aus funktionaler Sicht keinen Grund, warum dies für dieses bestimmte Szenario erforderlich sein sollte.

An dieser Stelle ist es wichtig anzumerken, dass mit einem Anspruch nahezu jedes Sicherheitselement in einer SharePoint-Website mit Ausnahme eines Websitesammlungsadministrators bereitgestellt werden kann. Glücklicherweise weisen bestimmte Bedingungen auf eine Suche nach einem Websitesammlungsadministrator hin. Wenn dies geschieht, verfügt das entityTypes-Array über ein Element: Users. Unter allen anderen Umständen gibt es mindestens sechs Elemente im entityTypes-Array. Wir fügen beim Auffüllen der Hierarchie also eine besondere Überprüfung hinzu, da wir keine Hierarchie möchten, von der wir von vornherein wissen, dass wir sie nie verwenden.

protected override void FillHierarchy(Uri context, string[] entityTypes,
      string hierarchyNodeID, int numberOfLevels,
      Microsoft.SharePoint.WebControls.SPProviderHierarchyTree hierarchy)
{                        

// Ensure that People Picker is asking for the type of entity that we 
// return; site collection administrator will not return, for example.
if (!EntityTypesContain(entityTypes, SPClaimEntityTypes.FormsRole))
      return;

// Check to see whether the hierarchyNodeID is null; it is when the control 
// is first loaded, but if a user clicks on one of the nodes, it will return
// the key of the node that was clicked. This lets you build out a 
// hierarchy as a user clicks something, instead of all at once. So I 
// wrote the code for that scenario, but I am not using it in that way.  
// Which means that I could have just as easily used an 
// if (hierarchyNodeID == null) in this particular implementation, instead
// of a switch statement.
switch (hierarchyNodeID)
{
      case null:
            // When it first loads, add all our nodes.
            hierarchy.AddChild(new 
                  Microsoft.SharePoint.WebControls.SPProviderHierarchyNode(
                  SqlClaims.ProviderInternalName, 
                  teamLabels[0], 
                  teamKeys[0], 
                  true));

            hierarchy.AddChild(new
                  Microsoft.SharePoint.WebControls.SPProviderHierarchyNode(
                  SqlClaims.ProviderInternalName,
                  teamLabels[1],
                  teamKeys[1],
                  true));

            hierarchy.AddChild(new
                  Microsoft.SharePoint.WebControls.SPProviderHierarchyNode(
                  SqlClaims.ProviderInternalName,
                  teamLabels[2],
                  teamKeys[2],
                  true));
            break;
      default:
            break;
} 
}

Das ist auch schon alles – ich überprüfe nur, ob die hierarchyNodeID NULL ist, und das ist beim ersten Laden des Steuerelements immer der Fall. Wenn es NULL ist, füge ich die Knoten zur Struktur im linken Fenster hinzu. Damit dieser Code funktioniert, kompiliere ich die Assembly erneut, füge sie wieder dem globalen Assemblycache hinzu und führe ein IISRESET durch. Danach kann ich auf die Website zugreifen und versuchen, die Berechtigungen zum Öffnen der Personenauswahl zu ändern. In Abbildung 3 wird die Personenauswahl nach der Implementierung dieses Codes angezeigt.

Abbildung 3. Personenauswahl mit Hierarchieknoten

An dieser Stelle möchte ich noch auf eine Sache hinweisen. Wenn Sie aufmerksam folgen, wundern Sie sich vielleicht, warum in der Personenauswahl Steve's SQL Claims Provider und nicht der Wert der Name-Eigenschaft aus dem Code (Basketball Teams) als Name für den Forderungsanbieter angegeben wird. Ehrlich gesagt war ich hier einfach faul. Was Ihnen als Name angezeigt wird, ist der ursprüngliche Name, den ich dem Forderungsanbieter gegeben habe. Nachdem ich das Szenario fertiggestellt hatte, beschloss ich, den Namen zu ändern. Ich habe jedoch nicht sämtliche Schritte ausgeführt, um ihn in der Forderungsanbieterliste zu aktualisieren. Aus diesem Grund wird Ihnen jetzt dieser Name dort angezeigt.

In Teil 3 untersuchen wir, wie die Suche nach Ansprüchen in der Personenauswahl mit dem benutzerdefinierten Forderungsanbieter aktiviert wird.

Teil 3: Suchen nach Ansprüchen

In den ersten beiden Teilen dieses Artikels haben wir gesehen, wie ein benutzerdefinierter Forderungsanbieter erstellt wird, wie eine Anspruchserweiterung ausgeführt und der Anbieter registriert wird und wie der Personenauswahl eine Hierarchie hinzugefügt wird. In Teil 3 beschreibe ich, wie die Suche nach Ansprüchen in der Personenauswahl mit dem benutzerdefinierten Forderungsanbieter implementiert wird. Ohne eine Möglichkeit zur Auswahl des benutzerdefinierten Anspruchs können wir auf der Website keine Berechtigungen auf Grundlage des Lieblingsbasketball-Teams bereitstellen.

Ich möchte mir zuerst etwas Zeit nehmen, dies zu verdeutlichen, da es sich hierbei um einen wichtigen Punkt handelt, der oft nicht verstanden wird. Die Bereitstellung von Berechtigungen auf der Grundlage eines Attributs des Benutzers anstelle der Identität des Benutzers eröffnet viele Möglichkeiten. Es kann bedeuten, dass mir (wie in diesem Szenario) nicht wichtig ist, wer Sie sind. Ich interessiere mich nicht dafür, wie Sie sich angemeldet haben. Ich möchte nicht wissen, ob Sie ein Windows-Benutzer oder ein Benutzer mit formularbasierter Authentifizierung sind.

Wichtig ist mir nur, welches Ihr Lieblingsbasketball-Team ist. Hier haben wir ein klassisches Problem aus Microsoft Office SharePoint Server 2007, das auch in SharePoint 2010 noch existiert – bei der Arbeit melde ich mich mit meinen Windows-Anmeldeinformationen, Steve Peschka, auf meiner SharePoint-Website an. Zu Hause greife ich jedoch über das Extranet auf die Website zu, und dazu muss ich die formularbasierte Authentifizierung verwenden.

In unserem Szenario wird davon ausgegangen, dass ich ein Benutzer mit formularbasierter Authentifizierung (user1) bin. Wo liegt das Problem? Für SharePoint handelt es sich um zwei verschiedene Benutzer. In SharePoint Server 2007 oder SharePoint 2010 gibt es keine Möglichkeit, eine Benutzerzuordnung durchzuführen und dabei angeben, dass der Windows-Benutzer Steve Peschka und der Benutzer user1 der formularbasierten Authentifizierung dieselbe Person ist.

Wissen Sie was? Das ist nicht mehr wichtig. Warum? Weil wir die Berechtigungen nicht auf Grundlage der Identität der Person zuweisen. Wir weisen Sie auf Grundlage des Lieblingsbasketball-Teams der Person zu. Das von mir implementierte Szenario ist vereinfacht. Sie können sich jedoch Unternehmensmetadaten vorstellen, die mit einer Person verknüpft sind. Der Forderungsanbieter führt eine Suche in einem anderen System aus, um alle unterschiedlichen Identitäten zu bestimmen, die von einer Person verwendet werden – Windows-Authentifizierung, formularbasierte Authentifizierung, SAP, CRM usw. – und ist in der Lage, einige andere Bezeichner oder Ansprüche dieser Identität zuzuordnen. Diese Ansprüche werden dann dazu verwendet, Zugriff auf Ressourcen zu gewähren.

Möchten Sie die einmalige Anmeldung zwischen Ihren verschiedenen Webanwendungen verwenden? Auch hier unterscheidet sich user1 in Webanwendung 1 von user1 in Webanwendung 2. Aber das ist auch völlig unwichtig. Solange ich den Anspruch mit dem Lieblingsbasketball-Team verwende, kann eine Person problemlos zwischen diesen Webanwendungen wechseln, da bei jeder Authentifizierung eine Erweiterung stattfindet. Ich behaupte nicht, dass diese Methode perfekt ist, denn das ist sie tatsächlich nicht. Aber sie kommt dem immerhin näher als vorherige Sicherheitsmodelle.

Gut, während Sie sich dies verdeutlichen, können wir nun zur Unterstützung der Suche in der Personenauswahl übergehen. Damit der benutzerdefinierte Forderungsanbieter die Suche unterstützt, müssen wir dafür sorgen, dass die folgenden Eigenschaften und Methoden der SPClaimProvider-Klasse unterstützt werden: SupportsSearch, SupportsResolve, FillSearch, FillResolve (die Überladung mit SPClaim als Eingabeparameter), FillSchema und FillEntityTypes.

Die Eigenschaften sind zu diesem Zeitpunkt einfach, deshalb wenden wir uns ihnen zuerst zu; sie werden im folgenden Code dargestellt.

public override bool SupportsSearch
{
      get 
      { 
            return true; 
      }
}

public override bool SupportsResolve
{
      get 
      { 
            return true; 
      }
}

Die FillSearch-Methode ist wahrscheinlich am interessantesten für Sie. Wir sehen uns das im folgenden Code einmal genauer an.

protected override void FillSearch(Uri context, string[] entityTypes, 
      string searchPattern, string hierarchyNodeID, int maxCount,
      Microsoft.SharePoint.WebControls.SPProviderHierarchyTree searchTree)
{

// Ensure that People Picker is asking for the type of entity that we 
// return; site collection administrator will not return, for example.
if (!EntityTypesContain(entityTypes, SPClaimEntityTypes.FormsRole))
      return;

// The counter to track what node we are in; it will be used to call into
// our helper arrays that were covered in part 1 and part 2 of this article.
int teamNode = -1;

// NOTE: If we were not using hierarchies in the People Picker, we would
// probably use a list of PickerEntity instances so that we could
// add them all to the People Picker in one call. I have stubbed it out
// here for demonstration purposes so you can see how you 
// would do it. 
// Picker entities that we will add if we find something.
// List<PickerEntity> matches = new List<PickerEntity>();

// The node where we will place our matches.
Microsoft.SharePoint.WebControls.SPProviderHierarchyNode matchNode = null;

// Look to see whether the value that is typed in matches any of our teams.
foreach (string team in ourTeams)
{
      // Increment team node tracker.
      teamNode += 1;

      // Simple way to do a string comparison to the search criteria.
      // This way, all a person has to type in to find Consolidated Messenger is "b".
      if (team.ToLower().StartsWith(searchPattern.ToLower()))
      {
            // We have a match, create a matching entity.
            // This is a helper method that I will explain later.
            PickerEntity pe = GetPickerEntity(team);

            // If we did not have a hierarchy, we would add it here
            // by using the list described previously.
            // matches.Add(pe);

            // Add the team node where it should be displayed; 
            // ensure that we have not already added a node to the tree
            // for this team's location.
            if (!searchTree.HasChild(teamKeys[teamNode]))
            {
                  // Create the node so that we can show our match in there too.
                  matchNode = new 
                  SPProviderHierarchyNode(SqlClaims.ProviderInternalName,
                  teamLabels[teamNode],
                  teamKeys[teamNode],
                  true);

                  // Add it to the tree.
                  searchTree.AddChild(matchNode);
             }
             else
                  // Get the node for this team.
                  matchNode = searchTree.Children.Where(theNode =>
                  theNode.HierarchyNodeID == teamKeys[teamNode]).First();

            // Add the picker entity to our tree node.
            matchNode.AddEntity(pe);
      }
}

// If we were adding all the matches at once,that is, if we were not using
// a hierarchy, then we would add the list of matches here.
// if (matches.Count > 0)
//    searchTree.AddEntities(matches);
}

Auch dieser Code ist an sich selbsterklärend. Der Benutzer hat etwas in das Suchfeld in der Personenauswahl eingegeben und auf die Suchschaltfläche geklickt. Daraufhin wird der Forderungsanbieter aufgerufen, da die SupportsSearch-Eigenschaft true zurückgibt. Die aufgerufene Methode ist FillSearch. In dieser Methode untersuchen wir, was der Benutzer eingegeben hat. Wir erhalten dies über den searchPattern-Eingabeparameter. Wir sehen uns alle Teamnamen an und bestimmen, ob einer davon mit dem Wert beginnt, der in das Suchfeld eingegeben wurde. Falls dies der Fall ist, erstellen wir eine neue PickerEntity, suchen oder erstellen einen Suchstruktur-Hierarchieknoten mit dem Ort des Teams und fügen unsere PickerEntity-Entität zu diesem Knoten hinzu.

Im vorherigen Code können wir anhand einer speziellen Hilfsfunktion namens GetPickerEntity erkennen, wohin der Name des gefundenen Teams weitergegeben wird. Dies wird im folgenden Code demonstriert.

private PickerEntity GetPickerEntity(string ClaimValue)
{

// Use the helper function!
PickerEntity pe = CreatePickerEntity();

// Set the claim that is associated with this match.
pe.Claim = CreateClaim(SqlClaimType, ClaimValue, SqlClaimValueType);

// Set the tooltip that is displayed when you pause over the resolved claim.
pe.Description = SqlClaims.ProviderDisplayName + ":" + ClaimValue;

// Set the text that we will display.
pe.DisplayText = ClaimValue;

// Store it here, in the hashtable **
pe.EntityData[PeopleEditorEntityDataKeys.DisplayName] = ClaimValue;

// We plug this in as a role type entity.
pe.EntityType = SPClaimEntityTypes.FormsRole;

// Flag the entry as being resolved.
pe.IsResolved = true;

// This is the first part of the description that shows
// above the matches, like Role: Forms Auth when
// you do an forms-based authentication search and find a matching role.
pe.EntityGroupName = "Favorite Team";

return pe;
}

Hier erstellen wir ein neues PickerEntity-Objekt. Wie Sie an den Codekommentaren ablesen können, ist die CreatePickerEntity-Methode der SPClaimProvider-Klasse eine weitere Hilfsfunktion in SharePoint. Auch hier empfiehlt es sich, nach Möglichkeit unbedingt auf die Hilfsfunktionen zurückzugreifen.

Nach der Erstellung des PickerEntity-Objekts benötigen wir eine Möglichkeit zu beschreiben, was "es" ist. In diesem Fall ist "es" ein Anspruch für ein Lieblingsbasketball-Team. Wir beschreiben dies für das System, indem wir einen Anspruch mit derselben Methode erstellen, die wir für den Code zur Anspruchserweiterung verwendet haben. Aus diesem Grund haben wir den Teamnamen an die Hilfsfunktion weitergegeben, damit sie das Lieblingsteam der Person in den Anspruch für das Lieblingsteam aufnehmen kann. Danach legen wir mehrere Eigenschaften für das PickerEntity-Objekt fest, damit es aussieht und sich verhält wie andere Ansprüche, die Ihnen für Windows-Ansprüche oder formularbasierte Authentifizierungsansprüche angezeigt werden. Danach wird die PickerEntity zurückgegeben, die wir erstellt haben.

Wir sind jedoch noch nicht ganz fertig. Wenn wir an diesem Punkt abbrechen, können wir den Anspruch in der Personenauswahl anzeigen und ihn auswählen. Wenn Sie auf die Schaltfläche OK klicken, um das Dialogfeld Personenauswahl zu schließen, wird der Anspruch im Eingabesteuerelement angezeigt. Die Anzeige erfolgt jedoch mit einer rotgeschlängelten Unterstreichung, die angibt, dass er nicht aufgelöst ist. Sie können den Anspruch an dieser Stelle nicht auflösen.

Bei dieser Vorgehensweise geschieht Folgendes. Wenn Sie im Dialogfeld Personenauswahl auf die Schaltfläche OK klicken, um es zu schließen, startet SharePoint eine weitere Abfrage des Forderungsanbieters für die FillResolve-Methode. Dabei handelt es sich um eine Überladungsmethode. Die Methode, in die der Aufruf beim Schließen des Dialogfelds Personenauswahl erfolgt, ist die Methode, die einen SPClaim-Eingabeparameter enthält. Wir sehen uns also die Implementierung dieser Methode etwas genauer an, und zwar im folgenden Code.

protected override void FillResolve(Uri context, string[] entityTypes, 
      SPClaim resolveInput, 
      List<Microsoft.SharePoint.WebControls.PickerEntity> resolved)
{

// Ensure that People Picker is asking for the type of entity that we 
// return; site collection administrator will not return, for example.
if (!EntityTypesContain(entityTypes, SPClaimEntityTypes.FormsRole))
      return;

// Same sort of code as in search, to validate that we have a match.
foreach (string team in ourTeams)
{
if (team.ToLower() == resolveInput.Value.ToLower())
{
      // We have a match; create a matching entity with helper method.
      PickerEntity pe = GetPickerEntity(team);

      // Add it to the return list of picker entries.
      resolved.Add(pe);
}
}

Die FillResolve-Methode ist einfach. Sie erinnern sich von Teil 1: Erweitern der Ansprüche und Registrieren des Anbieters in diesem Artikel, dass die Value-Eigenschaft der SPClaim-Klasse den Wert für den Anspruch enthält. Da in der Personenauswahl möglicherweise mehrere Elemente ausgewählt wurden, wie im Anspruch weitergegeben, führen wir erneut eine Enumeration unserer Teamliste aus, um zu sehen, ob der Anspruchswert mit einem unserer Teams übereinstimmt. Falls ja, rufen wir die Hilfsmethode auf, um ein PickerEntity-Objekt zu erstellen, und fügen es danach der Liste der PickerEntity-Instanzen für SharePoint hinzu. Jetzt wird uns nach der Auswahl in der Personenauswahl ein aufgelöster Eintrag im Eingabesteuerelement angezeigt.

Sie müssen noch zwei weitere Methoden implementieren: die FillSchema-Methode und die FillEntityTypes-Methode der SPClaimProvider-Basisklasse. In der FillSchema-Methode fügen wir die minimale Eigenschaft hinzu, die wir in der Personenauswahl verwenden möchten, nämlich den Anzeigenamen. Dazu fügen wir den Anzeigenamen dem Schema hinzu.

In der FillEntityTypes-Methode soll die Art des Anspruchs bzw. der Ansprüche, die der Forderungsanbieter verwendet, zurückgegeben werden. In diesem Fall haben wir den Anspruchstyp als SPClaimEntityTypes.FormsRole in der GetPickerEntity-Methode definiert. Deshalb habe ich diese Rolle der Liste der Entitätstypen hinzugefügt, was im folgenden Code verdeutlicht wird.

protected override void 
FillSchema(Microsoft.SharePoint.WebControls.SPProviderSchema schema)
{
// Add the schema element that we need at a minimum in our picker node.
schema.AddSchemaElement(new 
      SPSchemaElement(PeopleEditorEntityDataKeys.DisplayName, 
      "Display Name", SPSchemaElementType.Both));
}

protected override void FillEntityTypes(List<string> entityTypes)
{
// Return the type of entity claim that we are using (only one in this case).
entityTypes.Add(SPClaimEntityTypes.FormsRole);
}

In Abbildung 4 sehen Sie, wie die Personenauswahl nach der Suche nach wingtip dargestellt wird.

Abbildung 4. Suchen in der Personenauswahl

In Abbildung 5 sehen Sie, wie das Eingabesteuerelement dargestellt wird, nachdem wir den Anspruch hinzugefügt und auf OK geklickt haben.

Abbildung 5. Anzeige des Eingabesteuerelements nach dem Hinzufügen eines Anspruchs

Der Code ist nun fertig. Jetzt ist es an der Zeit, wieder an die Diskussion zu Beginn des Artikels anzuknüpfen. Wir können jetzt Berechtigungen auf Grundlage unseres Lieblingsbasketball-Teams bereitstellen. In diesem Fall habe ich beschlossen, dass Personen mit dem Lieblingsteam Wingtip Toys zum Inhalt der Website beitragen können. Ich habe diesen Anspruch der Gruppe Mitglieder hinzugefügt. In Abbildung 6 können Sie sehen, wie sich dies darstellt (Windows Claims ist der Name der Websitesammlung; lassen Sie sich nicht verwirren).

Abbildung 6. Hinzufügen eines Anspruchs zur Gruppe "Mitglieder"

Denken Sie daran, dass es nicht wichtig ist, wer Sie sind oder wie Sie sich anmelden. Ich habe in diesem Beispiel keinem Windows-Benutzer, keiner Windows-Gruppe, keinem Benutzer mit formularbasierter Authentifizierung und keiner Rolle mit formularbasierter Authentifizierung Rechte auf der Seite gewährt. Ich habe den Anspruch für Wingtip Toys der Gruppe Mitglieder hinzugefügt und darüber hinaus den Anspruch für Consolidated Messenger der Gruppe Besucher hinzugefügt.

Als Beweis sehen Sie in Abbildung 7 meine Liste aller Gruppen für die Websitesammlung.

Abbildung 7. Liste von Gruppenberechtigungen für eine Websitesammlung

Dies sollte Ihnen zeigen, wie leistungsstark die Anspruchsauthentifizierung und Anspruchsanbieter sein können. Im letzten Teil dieses Artikels zeige ich, wie Unterstützung für Personen implementiert wird, die einen Anspruchsnamen in das Eingabesteuerelement eingeben.

Teil 4: Unterstützung der Namensauflösung

In den ersten drei Teilen dieses Artikels haben wir fast die gesamte Unterstützung implementiert, die für die Erstellung eines End-to-End-Forderungsanbieters erforderlich ist. In diesem letzten Teil beschreibe ich die Implementierung der Unterstützung von Namensauflösung in das Eingabesteuerelement.

Um die Unterstützung von Namensauflösung hinzuzufügen, müssen wir die folgende Eigenschaft und Methode der SPClaimProvider-Klasse hinzufügen: die SupportsResolve-Eigenschaft und die FillResolve-Methode.

Glücklicherweise habe ich mich unter Teil 3: Suchen nach Ansprüchen bereits mit der Implementierung der SupportsResolve-Eigenschaft und einer der FillResolve-Methodenüberladungen beschäftigt. Deshalb ist dieser Abschnitt entsprechend kurz. Nachfolgend wird der Code für die Implementierung der anderen Überladung der FillResolve-Methode dargestellt, die nicht unter "Teil 3: Suchen nach Ansprüchen" behandelt wurde.

protected override void FillResolve(Uri context, string[] entityTypes, 
      string resolveInput, 
      List<Microsoft.SharePoint.WebControls.PickerEntity> resolved)
{

// Ensure that People Picker is asking for the type of entity that we 
// return; site collection administrator will not return, for example.
if (!EntityTypesContain(entityTypes, SPClaimEntityTypes.FormsRole))
      return;
 
// Same sort of code as in search, to validate that we have a match.
foreach (string team in ourTeams)
{
      if (team.ToLower() == resolveInput.ToLower())
      {
            // We have a match;, create a matching entity.
            PickerEntity pe = GetPickerEntity(team);

            // Add it to the return list of picker entries.
            resolved.Add(pe);
       }
}
}

Wenn Sie gut aufgepasst haben, ist dieser Codeabschnitt leicht verständlich. Falls Sie damit Probleme haben, lesen Sie Teil 3: Suchen nach Ansprüchen erneut.

Der Code ist nun fertig. Ich kann jetzt das Eingabesteuerelement aufrufen, einen Teamnamen eingeben und dann auf die Schaltfläche zum Auflösen klicken. In den folgenden Abbildungen wird das Eingabesteuerelement vor und nach der Namensauflösung angezeigt. In Abbildung 8 wird das Eingabesteuerelement nach der Eingabe des Teamnamens angezeigt.

Abbildung 8. Eingabesteuerelement vor der Auflösung

In Abbildung 9 sehen Sie das Eingabesteuerelement nach der Auflösung.

Abbildung 9. Eingabesteuerelement nach der Auflösung

Und damit sind wir am Ende angekommen. Ich hoffe, Sie finden diese Informationen hilfreich bei Ihren eigenen Projekten bezüglich der Anspruchsauthentifizierung.

Schlussbemerkung

Sie können mit einem Forderungsanbieter in SharePoint 2010 Ansprüche erweitern und Namensauflösung bereitstellen. Mithilfe der Anspruchsauthentifizierung können Sie Rechte auf der Grundlage von Ansprüchen zuweisen, ohne zu wissen, wer ein Benutzer ist oder wie er sich authentifiziert. Sie müssen lediglich die Attribute des Benutzers kennen. Sie können z. B. Unternehmensmetadaten verwenden, die mit einer Person verknüpft sind. Der Forderungsanbieter kann eine Suche in einem anderen System ausführen, um alle unterschiedlichen Identitäten zu bestimmen, die von einer Person verwendet werden – Windows-Authentifizierung, formularbasierte Authentifizierung, SAP, CRM usw. – und einige andere Bezeichner oder Ansprüche dieser Identität zuzuordnen. Diese Ansprüche werden dann dazu verwendet, Zugriff auf Ressourcen zu gewähren.

Weitere Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Steve Peschkas Blog: Share-n-dipity

• Steve Peschkas Blog: Replacing the Out-of-Box Name Resolution in SharePoint 2010—Part 2 (Ersetzen der Standardnamensauflösung in SharePoint 2010 – Teil 2)

• Security Resource Center | SharePoint 2010

• Sicherheitsbezogene Blogs, Ressourcencenter und SharePoint-Foren

• Tipps zu Ansprüchen – 1: Informationen zur anspruchsbasierten Authentifizierung in SharePoint 2010

• Tipp 2 zu Ansprüchen: Informationen zur anspruchsbasierten Authentifizierung in SharePoint 2010

• Exemplarische Vorgehensweise zu Ansprüchen: Erstellen von Forderungsanbietern für Webanwendungen mit formularbasierter Authentifizierung für SharePoint 2010

• Exemplarische Vorgehensweise zu Ansprüchen: Erstellen von Anspruchsanbietern für vertrauenswürdige Anmeldeanbieter für SharePoint 2010

• Exemplarische Vorgehensweise zu Ansprüchen: Erstellen der formularbasierten Authentifizierung für anspruchsbasierte SharePoint 2010-Webanwendungen mithilfe von ASP.NET SQL-Mitgliedschafts- und Rollenanbietern

• Exemplarische Vorgehensweise zu Ansprüchen: Erstellen der formularbasierten Authentifizierung für anspruchsbasierte SharePoint 2010-Webanwendungen mithilfe benutzerdefinierter Mitgliedschafts- und Rollenanbieter

• Exemplarische Vorgehensweise zu Ansprüchen: Erstellen eines vertrauenswürdigen Anmeldeanbieters (SAML-Anmeldung) für SharePoint 2010

• Anspruchsanbieter in Microsoft SharePoint 2010

• Eingehende Ansprüche: Anmelden bei SharePoint

• Microsoft.SharePoint.Administration.Claims

• Planung, Upgrade, Migration, Verwaltung, Konfiguration und Setup

• Videopräsentationen zu Sicherheit in SharePoint 2010

• Schulung erfahrener Entwickler für SharePoint 2010

• SharePoint Developer Center