Partager via

Projekt „Benutzerdefinierter Azure-Anspruchsanbieter für SharePoint“ – Teil 1

  • Article

Veröffentlichung des Originalartikels: 11.02.2012

Hallo allerseits! Es ist schon eine Weile her, dass ich neue Inhalte zu SAML-Ansprüchen bereitgestellt habe. Daher möchte ich nun ein paar weitere Beiträge verfassen, die einige meiner Lieblingsthemen – SharePoint, SAML, benutzerdefinierte Anspruchsanbieter, das CASI Kit und Azure – in Verbindung bringen. Dies ist der erste Teil einer Reihe, in der ich eine Machbarkeitsstudie (Proof of Concept) zusammen mit dem Quellcode, den Sie gern frei verwenden können, liefern werde. Darin wird die Erstellung eines benutzerdefinierten Anspruchsanbieters für SharePoint unter Verwendung von Windows Azure als Datenquelle demonstriert. Auf einer allgemeinen Ebene sieht die Implementierung etwa folgendermaßen aus:

  • Benutzer melden sich an der Website mit SAML-Verbundauthentifizierung mit ACS an. Auf der ACS-Seite konfiguriere ich einige Identitätsanbieter – z. B. Google, Yahoo und Facebook. Somit melden sich die Benutzer z. B. mit ihrer Google-E-Mail-Adresse an und werden dann nach der Authentifizierung auf die Website umgeleitet.
  • Mithilfe von Azure-Warteschlangen leite ich Anspruchsinformationen über Benutzer weiter und fülle den Azure-Tabellenspeicher auf.
  • Ich verwende eine WCF-Anwendung als Front-End für Anforderungen von Daten im Azure-Tabellenspeicher und zum Ablegen neuer Elemente in der Warteschlange. Wir erstellen eine Vertrauensstellung zwischen der SharePoint-Website und dieser WCF-Anwendung, um zu steuern, wer Zugriff hat und was er anzeigen und tun kann.
  • Auf der SharePoint-Seite erstelle ich einen benutzerdefinierten Anspruchsanbieter. Er ruft die Liste der unterstützten Anspruchstypen ab und erledigt die Suche in der Personenauswahl und die Namensauflösung. Er verwendet das CASI Kit zur Kommunikation mit Windows Azure.

Wenn wir fertig sind, haben wir eine vollständige integrierte SharePoint-zu-Cloud-Umgebung. Ich hoffe, Sie haben Spaß daran.

In Teil 2 bin ich alle Komponenten durchgegangen, die in der Cloud ausgeführt werden – die Datenklassen für die Arbeit mit Azure-Tabellenspeicher und Warteschlangen, eine Workerrolle zum Lesen von Elementen aus Warteschlangen und Auffüllen des Tabellenspeichers sowie ein WCF-Front-End, mit dem eine Clientanwendung neue Elemente in der Warteschlagen erstellen und alle standardmäßigen Aktionen mit der SharePoint-Personenauswahl ausführen kann: eine Liste der unterstützten Anspruchstypen bereitstellen, nach Anspruchswerten suchen und Ansprüche auflösen.

In Teil 3 erstelle ich alle Komponenten, die in der SharePoint-Farm verwendet werden. Dazu gehört auch eine auf dem CASI Kit basierende benutzerdefinierte Komponente, die die gesamte Kommunikation zwischen SharePoint und Azure verwaltet. Es gibt ein benutzerdefiniertes Webpart, das Informationen über neue Benutzer erfasst und in einer Azure-Warteschlange ablegt. Schließlich gibt es einen benutzerdefinierten Anspruchsanbieter, der mit dem Azure-Tabellenspeicher über WCF – über die benutzerdefinierte CASI Kit-Komponente – kommuniziert, um die Funktionalität des Eingabesteuerelements und der Personenauswahl zu ermöglichen.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter The Azure Custom Claim Provider for SharePoint Project Part 1.