Le fournisseur de revendications personnalisées Azure pour projet SharePoint - Partie 1

Article d’origine publié le samedi 11 février 2012

Bonjour ! Il y a un bon bout de temps que je n’ai pas publié de contenu sur les revendications SAML, j’ai donc décidé d’écrire un billet sur ce thème en faisant des liens avec mes sujets favoris : SharePoint, SAML, les fournisseurs de revendications personnalisées, le kit CASI et Azure. Ce billet est le premier d’une série dans laquelle je fournirai une validation de principe complète, avec le code source que vous pourrez utiliser librement à votre guise, permettant de créer un fournisseur de revendications personnalisées pour SharePoint qui utilise Windows Azure comme source de données. À un niveau élevé, l’implémentation ressemblera à ceci :

• Les utilisateurs se connecteront au site à l’aide de la fédération SAML avec ACS. Du côté ACS, je vais configurer quelques fournisseurs d’identité – probablement Google, Yahoo et Facebook. Les utilisateurs se connecteront en utilisant leur adresse de messagerie Google par exemple, et une fois authentifiés seront redirigés vers le site.
• J’utiliserai les files d’attente Azure pour acheminer les informations de revendication sur les utilisateurs et remplir le stockage en table Azure.
• J’aurai une application WCF que j’utiliserai pour les demandes frontales de données dans le stockage en table Azure, ainsi que pour déposer de nouveaux éléments dans la file d’attente. Nous allons créer une approbation entre le site SharePoint et cette application WCF pour contrôler qui obtient l’accès et ce qu’il peut voir et faire.
• Du côté de SharePoint, je vais créer un fournisseur de revendications personnalisées. Il obtiendra la liste des types de revendications pris en charge, et effectuera la recherche et la résolution de nom du sélecteur de personnes. En fait, il utilisera le kit CASI pour communiquer avec Windows Azure.

Au final, nous aurons un environnement entièrement intégré de bout en bout SharePoint-vers-Cloud. En espérant que vous apprécierez cela.

Dans la Partie 2, j’explore tous les composants qui s’exécutent dans le Cloud – les classes de données qui sont utilisées pour travailler avec les files d’attente et le stockage en table Azure, un rôle de travail pour lire des éléments dans des files d’attente et remplir le stockage tabulaire et un serveur frontal WCF qui permet à une application cliente de créer de nouveaux éléments dans la file d’attente et faire tout le travail standard du sélecteur de personnes SharePoint – fournir une liste des types de revendications pris en charge, rechercher les valeurs de revendication et résoudre les revendications.

Dans la Partie 3, je crée tous les composants utilisés dans la batterie de serveurs SharePoint, notamment un composant personnalisé basé sur le kit CASI, qui gère toutes les communications entre SharePoint et Azure. Il y a également un composant WebPart personnalisé qui capture les informations sur les nouveaux utilisateurs et les place dans une file d’attente Azure. Enfin, il y a un fournisseur de revendications personnalisées qui communique avec le stockage tabulaire Azure via un serveur WCF - par le biais du composant personnalisé du kit CASI - pour activer le contrôle de la saisie et les fonctionnalités du sélecteur de personnes.

Ce billet de blog a été traduit de l’anglais. Vous trouverez la version originale ici The Azure Custom Claim Provider for SharePoint Project Part 1