Traduction

Cet article est la traduction la plus fidèle possible de l'article original de Steve Peschka, The Claims, Azure and SharePoint Integration Toolkit Part 2.

Introduction

Ceci est la deuxième partie d'une série en six parties sur le CASI (Claims, Azure and SharePoint Integration) Kit.

  • Partie 1 : une introduction présentant une vue d'ensemble de l'intégralité du « framework » et de la solution, et qui décrit ce que la série va tâcher de couvrir.
  • Partie 2 : la partie « instructions et lignes directrices » du CASI Kit. Cela commence par faire de WCF le « frontend » pour toutes vos données - cela pourrait être des jeux de données, du XML, des classes personnalisées ou tout simplement de l'HTML. Dans la première phase, nous prenons votre service WCF standard et en faisons un service prenant en charge les revendications - c'est ce qui nous permet de prendre le jeton d'utilisateur de SharePoint et de le transmettre, indépendamment des limites des applications ou des centres de données, vers nos applications WCF personnalisées. Dans la deuxième phase, j'éplucherai la liste de toutes les choses à effectuer pour faire passer cette application WCF classique de « hébergée en local » à « hébergée dans Windows Azure ». Une fois cela terminé, vous aurez le « backend » en place pour assurer une prise en charge multi-applications, multi-centres de données avec l'authentification intégrée.
  • Partie 3 : décrit l'assembly de la trousse d'outils personnalisé qui fournit « le ciment » pour connecter votre application WCF prenant en charge les revendications dans le cloud et votre ferme SharePoint. J'expliquerai comment utiliser cet assembly, je parlerai du contrôle personnalisé plutôt simple que vous devez créer (environ 5 lignes de code) et comment vous pouvez l'héberger dans une page du répertoire « _layouts » comme moyen de récupérer et d'effectuer le rendu des données dans un web part. L'intégralité du code source de l'exemple de contrôle personnalisé et de la page « _layouts » sera également publiée.
  • Partie 4 : le web part que j'inclus dans le CASI Kit. Il fournit une solution sans code, prête à l'emploi, qui vous permet de vous raccorder et de vous connecter à une requête asynchrone côté client pour récupérer des données à partir de votre service hébergé dans le cloud, et de les afficher ensuite dans le web part. Il dispose également « d'accroches » intégrées afin que vous puissiez le personnaliser un peu et utiliser vos propres fonctions JavaScript pour effectuer le rendu des données.
  • Partie 5 : un bref examen de quelques exemples d'applications qui illustrent quelques autres scénarios pour utiliser le contrôle personnalisé que vous aurez construit dans la troisième partie dans d'autres cas de figures communs. L'un de ces scénarios utilisera le contrôle pour récupérer certains types de données utilisateur ou de données de configuration et les stocker dans le cache ASP.NET, puis les utiliser dans un web part personnalisé. L'autre scénario utilisera le contrôle personnalisé pour récupérer des données d'Azure et de les utiliser dans une tâche personnalisée ; dans le cas présent, un travail du minuteur SharePoint personnalisé. L'intégralité du code source de ces exemples d'applications sera également publiée.
  • Partie 6 : article complémentaire contenant quelques conseils sur l'utilisation de SQL Azure afin que vous puissiez l'intégrer facilement et rapidement dans vos projets de développement SharePoint 2010 avec Windows Azure.

Le CASI Kit : Partie 2 - Les « instructions et lignes directrices »

La première partie de cette série présentait une vue d'ensemble de l'intégralité du « framework » et de la solution, et décrivait les objectifs de chacun des articles de la série.

Dans cet article, nous allons nous concentrer sur le modèle relatif à l'approche suivie :

  1. utiliser une application WCF personnalisée en tant que « frontend » pour vos données et le contenu ;
  2. rendre l'application capable de prendre en charge les revendications ;
  3. apporter des modifications supplémentaires pour pouvoir transférer l'application vers le cloud Windows Azure.

Utilisation de WCF

Le point de départ du « framework » CASI Kit est que toutes les données d'application utilisent une application WCF en tant que « frontend ». À l'instar de toutes les applications personnalisées, il s'agit d'un élément que vous le développeur allez devoir créer. Il n'y quasiment aucune connaissance spécifique à SharePoint requise pour cette partie de votre projet - n'importe quel développeur .NET qui sait utiliser Visual Studio pour créer une application WCF peut le faire. Si votre objectif final est d'héberger ce service WCF dans Windows Azure, je vous conseille vivement d'utiliser le kit de développement de Windows Azure pour télécharger les modèles de création d'applications Azure, puis de commencer d'abord par créer une application WCF Azure depuis le début. Il existe une limitation importante à comprendre au sujet de la version actuelle du CASI Kit qu'il est bon de souligner ici. Le CASI Kit ne prend effectivement en charge que l'envoi des types de données .NET principaux en tant que paramètres aux méthodes WCF. Ainsi, les types string, bool, int et date fonctionnent bien, mais il n'existe pas de méthode pour passer une classe personnalisée en tant que paramètre. Toutefois, si vous avez besoin de faire cela, je vous conseille de créer le paramètre en tant que chaîne et de dé-sérialiser votre paramètre en XML avant d'appeler votre méthode WCF, puis de le ré-sérialiser en une instance d'objet dans votre code WCF. À part cela, il n'y a aucunes limitations significatives que j'ai vu jusqu'à présent, mais je suis sûr qu'une liste de souhaits ne va pas tarder à se constituer, une fois que ce kit aura été plus largement adopté et utilisé. Soit dit brièvement en passant, le kit que vous voyez aujourd'hui n'est rien d'autre que la version 1.0 de mes propres idées sur la façon dont nous pourrions raccorder toutes ces choses ensemble et a été conçu pour répondre aux scénarios de base auxquels j'ai pensés et que j'ai décidé étaient importants. Je n'ai aucun doute sur le fait qu'il y aura amplement de la place pour de l'amélioration au fur et à mesure que des gens l'utiliseront.

Rendre l'application capable de prendre en charge les revendications

Une fois l'application WCF créée, la prochaine étape consiste à la rendre capable de prendre en charge les revendications. Pour cette étape, je ne peux m'attribuer aucun mérite. Je me suis engagé dans cette voie et vais vous orienter vers l'excellente série d'articles en quatre parties qu'a rédigée Eric White de l'équipe Office pour décrire comment intégrer les revendications de SharePoint dans une application WCF.

Voir la mise à jour ci-dessous à propos de l'obtention d'un exemple de fichier web.config si vous ne souhaitez pas mettre en œuvre l'intégration ou si le blog d'Eric est inaccessible.

Supposant que vous avez déjà créé votre service WCF, je commencerai par la deuxième partie de la série d'articles d'Eric : Création d'un service Web prenant en charge les revendications et sa consommation à partir de SharePoint BCS - Partie 2 : Détermination de l'identité de l'appelant au sein du service Web WCF.

Vous devez également continuer et effectuer les étapes qu'il décrit dans la troisième partie : Création d'un service Web prenant en charge les revendications et sa consommation à partir de SharePoint BCS - Partie 3 : Établissement de la confiance entre un service Web WCF et le Security Token Service de SharePoint 2010.

Pour cela, vous devez commencer à la section intitulée Établir la confiance entre le service Web et le serveur SharePoint. Vous devez effectuer toutes les étapes à partir de ce point, à savoir copier l'empreinte numérique du certificat de signature de jetons du Security Token Service de SharePoint ainsi que d'autres informations dans le fichier web.config de votre application WCF. Il y a cependant d'autres points supplémentaires importants :

  • Je ne suivrais pas à la lettre les étapes relatives au certificat SSL dans la troisième partie de la série d'Eric, car l'utilisation d'un certificat auto-signé ne sera pas très utile lorsque votre application sera hébergée dans Windows Azure. Si vous n'avez rien d'autre de disponible, c'est ce qu'il faudra faire, mais en général, vous devriez prévoir d'obtenir un certificat SSL approprié auprès d'une autorité de certification approuvée pour votre application WCF Windows Azure.
  • Il y a un point dans cette procédure qui est légèrement inexact. Eric parle d'ajouter le certificat SSL utilisé sur le service web à la liste de SPTrustedRootAuthorities dans SharePoint uniquement si vous utilisez un certificat auto-signé. Au fait, vous devriez tout le temps ajouter tout certificat dans la chaîne d'approbation de certificat SSL au SPTrustedRootAuthorities de SharePoint. Par exemple, mon application WCF est sécurisée avec un certificat générique qui ressemble a quelque chose du style *.vbtoys.com. *.vbtoys.com possède un certificat d'autorité racine de vbtoys.com, il me faut donc ajouter le fichier .CER (c'est-à-dire, la clé publique) pour le certificat racine de vbtoys.com à mes autorités racines de confiance dans SharePoint. Vous pouvez le faire en Powershell comme je l'ai décrit dans divers billets de blog ou via l'Administration centrale, comme décrit ici : http://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx

Vous n'avez pas besoin de suivre les étapes de la quatrième partie de la série d'Eric. Une fois que vous aurez effectué les étapes décrites ci-dessus, vous disposerez d'une application WCF prenant en charge les revendications de SharePoint. Dans la phase finale de cet article, je vous décrirai les étapes supplémentaires à effectuer afin de transférer votre application vers Windows Azure.

Faire fonctionner l'application dans Windows Azure

Maintenant que vous disposez d'une application WCF Azure fonctionnelle, il y a quelques tâches supplémentaires à effectuer afin de permettre à l'application de continuer à prendre en charge l'authentification basée sur les revendications et les jetons via Windows Identity Framework (WIF), et afin de l'héberger dans le cloud Windows Azure. Établissons simplement et examinons de près la liste ci-dessous :

  1. Configurez votre projet WebRole (c'est-à-dire, votre projet WCF) de sorte qu'il utilise un répertoire virtuel local pour le débogage. Je trouve cela plus facile à travailler avec que le serveur de développement VS.NET pour des éléments utilisant des certificats, ce qui sera votre objectif. Pour modifier cela, double-cliquez sur les propriétés du projet WebRole, puis cliquez sur l'onglet Web. Sélectionnez le bouton radio indiquant « Utiliser le serveur Web IIS local », puis cliquez sur le bouton « Créer un répertoire virtuel ». Une fois le répertoire virtuel créé, vous pouvez fermer les propriétés de projet.
  2. Ajoutez une référence à Microsoft.Identity dans votre projet WebRole. Vous devez changer la référence en Copy Local = true et Specific Version = false. Cela s'avère nécessaire pour copier l'assembly WIF dans le cloud avec votre package d'application.
  3. Téléchargez ce correctif WCF : http://archive.msdn.microsoft.com/KB981002/Release/ProjectReleases.aspx?ReleaseId=4009 pour Windows 7 et Windows Server 2008 R2, et http://code.msdn.microsoft.com/KB971842/Release/ProjectReleases.aspx?ReleaseId=3228 pour Windows 7 et Windows Server 2008.
  4. Vous devez ajouter cet attribut à votre classe WCF . Ainsi par exemple, la classe ressemble à ceci :
     
    Sélectionnez
    namespace CustomersWCF_WebRole
    
    {
    
        [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
    
        public class Customers : ICustomers
    
        {
    
  5. Vous devez inclure les données de configuration suivantes dans l'élément de comportement utilisé par votre service. Cela corrige les problèmes susceptibles de se produire avec les affectations de ports aléatoires dans l'environnement Azure. Pour le tester en local, vous allez devoir obtenir le correctif décrit au point 3 ci-dessus :
     
    Sélectionnez
              <useRequestHeadersForMetadataAddress>
    
                <defaultPorts>
    
                  <add scheme="http" port="80" />
    
                  <add scheme="https" port="443" />
    
                </defaultPorts>
    
              </useRequestHeadersForMetadataAddress>
    

    Voici un exemple dans le contexte du web.config pour mon service WCF :

     
    Sélectionnez
        <behaviors>
    
          <serviceBehaviors>
    
            <behavior name="CustomersWCF_WebRole.CustomersBehavior">
    
              <federatedServiceHostConfiguration name="CustomersWCF_WebRole.Customers"/>
    
              <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
    
              <serviceDebug includeExceptionDetailInFaults="false"/>
    
              <useRequestHeadersForMetadataAddress>
    
                <defaultPorts>
    
                  <add scheme="http" port="80" />
    
                  <add scheme="https" port="443" />
    
                </defaultPorts>
    
              </useRequestHeadersForMetadataAddress>
    
            </behavior>
    
          </serviceBehaviors>
    
        </behaviors>
    
  6. D'abord, téléchargez le certificat SSL que vous utilisez pour l'application WCF vers le portail développeur Azure.
  7. La classe de base du CASI Kit est contrainte d'utiliser du SSL, donc vous devez implémenter la prise en charge du SSL dans votre application WCF Windows Azure. Espérons que cela devrait être un préalable requis pour passer des données potentiellement sensibles entre un service cloud et la ferme SharePoint. Ajoutez ensuite le certificat aux propriétés du rôle Azure dans Visual Studio, en double-cliquant sur le nom de projet WebRole (dans le dossier Roles). J'ai constaté qu'utiliser un certificat générique fonctionnait bien. Toutefois, vous avez besoin d'un certificat PFX, et veillez à exporter tous les certificats de la chaîne lorsque vous créez le fichier PFX. Azure les développera tous davantage lorsque vous téléchargerez le fichier vers le portail développeur.

  8. Votre certificat SSL devrait être pour quelconqueNom.votreNomDns.com, bien que toutes les applications Azure soient hébergées sur cloudapp.net. Par exemple, mon certificat SSL était un certificat générique pour *.vbtoys.com. Dans le DNS, j'ai créé un enregistrement CNAME appelé azurewcf.vbtoys.com, et il faisait référence à myAzureApp.cloudapp.net. Ainsi, lorsque j'établis une connexion vers https://azurewcf.vbtoys.com, mon certificat fonctionne, parce que ma requête et mon certificat SSL sont pour *.vbtoys.com, mais le DNS redirige ma requête en fonction de l'enregistrement CNAME, qui est myAzureApp.cloudapp.net.
  9. Dans votre projet Azure, double-cliquez sur le nom de projet WebRole (dans le dossier Roles) et définissez les propriétés ci-après comme suit :
    1. Onglet « Configuration » : désactivez la case à cocher « Lancer le navigateur » pour : le point de terminaison HTTP et le point de terminaison HTTPS.
    2. Onglet « Certificats » : ajoutez le certificat que vous allez utiliser pour SSL avec votre service. Par exemple, dans mon laboratoire, j'utilise un certificat générique émis par mon domaine pour l'ensemble de mes serveurs Web, par conséquent j'y ai ajouté mon certificat générique.
    3. Onglet « Points de terminaison » : activez les cases à cocher pour HTTP et HTTPS (les noms doivent être HttpIn et HttpsIn respectivement). Dans la section HTTPS, la zone de liste déroulante correspondant au nom du certificat SSL devrait maintenant contenir le certificat SSL que vous avez ajouté à l'étape « b ».
  10. Si vous disposez d'une méthode WCF qui renvoie un script, la balise script doit inclure l'attribut DEFER pour fonctionner correctement lors de l'utilisation du web part qui est inclus dans le CASI Kit, ou si votre propre fonction JavaScript l'assigne à la propriété innerHTML d'une balise. Par exemple, votre balise script devrait ressembler à ceci : <script defer language='javascript'>
  11. Si vous disposez d'une méthode WCF qui renvoie du contenu qui inclut d'autres balises de mise en forme, comme <style>, vous devez les inclure dans une balise <pre>, sinon, elles ne seront pas traitées correctement lors de l'utilisation du web part qui est inclus dans le CASI Kit, ou si votre propre fonction JavaScript l'assigne à la propriété innerHTML d'une balise. Par exemple, le contenu renvoyé avec une balise <style> devrait ressembler à ceci : <pre><style>.foo {font-size:8pt;}</style></pre>

Ce sont là les étapes qui sont nécessaires pour configurer l'application WCF a être hébergée dans Azure ; voici quelques conseils supplémentaires qui peuvent s'avérer utiles, et dans certains cas indispensables, en fonction de votre implémentation :

  1. Utilisez le nom entièrement qualifié lors de la création de l'adresse du point de terminaison qui consomme le service, c'est-à-dire « machineName.foo.com » au lieu de « machineName » simplement. Cela transitera de façon plus nette vers le format définitif hébergé sur Windows Azure et peut également corriger les erreurs qui surviennent lorsque votre certificat SSL est conçu pour utiliser un nom de domaine entièrement qualifié.
  2. Vous voudrez peut-être ajouter cet attribut : httpsGetEnabled="true" à cet élément : <serviceMetadata httpGetEnabled="true" />, si vous souhaitez obtenir votre WSDL sur SSL. Toutefois, il y a actuellement un bogue dans SharePoint Designer qui vous empêche d'utiliser SSL pour WSDL.
  3. Pour des conseils sur le débogage et la connexion de données, voir mon article à l'adresse : http://blogs.technet.com/b/speschka/archive/2010/09/19/azure-development-tips-for-debugging-and-connection-strings.aspx
  4. Dans la plupart des cas, vous devriez présumer que l'espace de noms de votre service WCF va être http://tempuri.org. Pour des instructions sur la façon de le changer, lisez l'article à l'adresse : http://blogs.infosupport.com/wcf-namespaces-in-wsdl/

Le service WCF fini

Si vous avez suivi toutes les étapes de configuration ci-dessus et déployé votre application WCF sur Windows Azure, lorsqu'un utilisateur effectue un appel vers ce service WCF à partir d'un site SharePoint, vous allez également obtenir l'intégralité de son jeton d'utilisateur, ainsi que toutes les revendications qui y sont associées. Il convient aussi de noter qu'à l'issue de ces modifications, le service WCF fonctionnera aussi en local, ainsi il est plutôt facile de tester si vous souhaitez expérimenter quelques modifications incrémentielles avant de transférer l'application vers le cloud. Disposer de ce jeton d'utilisateur vous permet de faire des choses très intéressantes dans votre service WCF. Par exemple, dans votre service WCF, vous pouvez énumérer toutes les revendications d'un utilisateur et prendre toutes sortes de décisions en matière de permissions affinées en vous basant dessus. Voici un exemple d'utilisation de LINQ sur l'ensemble des revendications d'un utilisateur afin de déterminer si l'utilisateur actuel est un administrateur, car si tel est le cas, un niveau de détail supplémentaire sera renvoyé dans la requête :

 
Sélectionnez
//look for the claims identity

IClaimsIdentity ci =

System.Threading.Thread.CurrentPrincipal.Identity as IClaimsIdentity;

 

if (ci != null)

{

//see if there are claims present before running through this

       if (ci.Claims.Count > 0)

       {                       

       //look for a group claim of domain admin

var eClaim = from Microsoft.IdentityModel.Claims.Claim c in ci.Claims

              where c.ClaimType ==

"http://schemas.microsoft.com/ws/2008/06/identity/claims/role" &&

                     c.Value == "Domain Admins"

                     select c;

 

              //see if we got a match

              if (eClaim.Count() > 0)

                     //there's a match so this user has the Domain Admins claim

                     //do something here

}

}

Ce qu'il y a d'également intéressant, c'est que vous pouvez aussi effectuer des demandes d'autorisation directement sur vos méthodes WCF. Par exemple, supposons que vous disposez d'une méthode WCF qui interroge un magasin de données et renvoie une liste des PDG des sociétés clientes. Vous ne souhaiterez pas que cette information soit accessible à l'ensemble des employés, mais uniquement aux responsables des ventes. Une manière astucieuse et facile d'implémenter cela est d'utiliser une demande PrincipalPermission sur la méthode, comme ceci :

 
Sélectionnez
//the customer CEO list should not be shared with everyone,

//so only show it to people in the Sales Manager role

[PrincipalPermission(SecurityAction.Demand, Role = "Sales Managers")]

public string GetCustomerCEOs()

{

//your code goes here

}

Maintenant, si quelqu'un essaie d'appeler cette méthode et s'il ne possède pas de revendication associée au rôle « Sales Managers », il se verra alors refuser l'accès s'il exécute du code qui essaie d'appeler cette méthode. Très cool !

Il est également important de comprendre que ce mécanisme ne peut pas être déjoué par une usurpation d'identité. Par exemple, vous ne pouvez pas tout simplement créer votre propre domaine dans un laboratoire, y ajouter un compte et créer un rôle « Sales Manager » auquel vous ajoutez ce compte. La raison pour laquelle cela ne fonctionnera pas nous ramène aux étapes que vous avez effectuées lorsque vous avez travaillé les billets d'Eric White (dans la section ci-dessus intitulée « Rendre l'application capable de prendre en charge les revendications »). Si vous vous rappelez, vous avez ajouté l'empreinte numérique du certificat de signature de jetons utilisé par le Security Token Service (STS) de SharePoint. Ce qui veut dire, lorsqu'une revendication parvient à votre application WCF, elle va rechercher le jeton qui doit être signé par la clé publique du Security Token Service de SharePoint. Seul le Security Token Service de SharePoint peut le signer avec cette clé publique, car c'est la seule entité qui possède la clé privée pour ce certificat de signature de jetons. Cela vous assure que seul quelqu'un qui s'est authentifié auprès de cette ferme SharePoint sera en mesure d'utiliser le service WCF, et que les utilisateurs ne disposeront que des revendications qui leur ont été accordées au moment où ils se sont connectés. Toutefois, ce qui est également intéressant a ce propos, c'est que cela inclut non seulement les revendications qui ont été accordées aux utilisateurs lorsqu'ils se sont authentifiés auprès de leur annuaire des utilisateurs, mais également les revendications supplémentaires qui leur ont été accordées par les fournisseurs de revendications personnalisés via la fonctionnalité d'augmentation des revendications dans SharePoint. Ainsi, il s'agit vraiment d'une solution globale réellement intégrée.

Mise à jour du 06/08/2011 : Étant donné que le blog d'Eric White a changé d'adresse et que je ne suis pas sur pour combien de temps encore l'ancien sera toujours en ligne, j'ai créé un exemple de fichier web.config avec tout ce qui est confiance SAML SharePoint, et je l'ai inclus dans le fichier compressé joint à cet article. Les parties que vous devez modifier pour votre projet sont clairement marquées avec un commentaire html et cinq astérisques comme ceci :<!-- *****. Il suffit de chercher ceux-la et de mettre à jour pour refléter votre projet et votre ferme SharePoint et tout devrait fonctionner.

Prochaines étapes

Dans le prochain article, je vais commencer à décrire la classe de base personnalisée et le web part qui sont inclus dans le CASI Kit, et qui vont vous permettre de vous connecter à votre nouvelle application WCF Azure très rapidement et facilement. En outre, à partir de maintenant j'utiliserai un service WCF que j'ai écrit pour le CASI Kit comme moyen d'illustrer la fonctionnalité. Je joins à cet article le fichier .cs que j'ai utilisé pour ce service. Vous ne pourrez pas l'utiliser en l'état, mais, il est inclus uniquement pour que vous puissiez voir les différentes méthodes qu'il contient, le type de données qu'il contient, et comment certaines fonctionnalités ont été implémentées pour ce kit. Au cours des articles suivants, vous me verrez principalement utiliser les méthodes a) GetAllCustomersHtml, b) GetCustomerCEOs et c) GetAllCustomers. Elles sont intéressantes, car elles a) renvoient du HTML (qui sera de facto le type de retour préféré pour afficher des données dans les web parts), b) utilisent une demande PrincipalPermission et c) montrent comment vous pouvez renvoyer un type de classe personnalisé à partir de votre application WCF et utiliser ce même type de classe enrichi après avoir renvoyé ces données dans SharePoint avec le CASI Kit.

Conclusion

Dans cette deuxième partie de notre série d'articles, nous nous sommes penchés et avons vu comment utiliser une application WCF personnalisée comme « frontend » pour les données et le contenu, comment rendre l'application capable de prendre en charge les revendications et comment apporter des modifications supplémentaires afin de pouvoir transférer l'application vers le cloud Windows Azure.

Liens

Vous trouverez en pièce jointe de cet article le lien vers le fichier compressé contenant la version Word de l'article en anglais, le fichier .cs utilisé pour le service WCF que l'auteur a écrit pour le CASI Kit, et l'exemple de fichier web.config créé par l'auteur.

Le projet CASI Kit sur CodePlex : ici

Remerciements

Je tiens ici à remercier Steve Peschka de m'avoir autorisé à traduire son article.
Je remercie xyz pour sa relecture technique et ses propositions.
Je remercie également abc pour sa relecture orthographique et ses propositions.