Article initial publié le samedi 07/05/2011

Dans le premier billet de la série (http://blogs.technet.com/b/speschka/archive/2011/05/05/federated-saml-authentication-with-sharepoint-2010-and-azure-access-control-service-part-1.aspx), j’avais expliqué comment configurer SharePoint de façon à établir une approbation directement auprès du service ACS (Azure Access Control) dans le but de fédérer l’authentification entre ADFS, Yahoo, Google et Windows Live et enfin accéder à SharePoint.  Dans la 2ème partie, je vais partir d’un scénario similaire à la différence près que son implémentation réelle est inversée par rapport à la 1ère partie : nous allons bien définir une approbation-type entre SharePoint et ADFS, mais nous configurerons ACS en tant que fournisseur d’identités dans ADFS, ce qui nous redirigera vers l’ouverture de session, puis nous renverra à SharePoint.  Ce type d’approbation, en tout cas entre SharePoint et ADFS, est probablement plus familier des utilisateurs de SharePoint et s’avère actuellement mieux adapté à un scénario partagé par un grand nombre d’entreprises.

Comme dans la 1ère partie, je ne vais pas entrer dans les détails techniques de la définition et de la configuration d’ACS. Je laisserai le soin aux équipes spécialisées de le faire à ma place.   Donc, pour la 2ème partie, voici les étapes à suivre pour se connecter :

1.       Définissez votre application Web et votre collection de sites SharePoint, configurées avec ADFS.

  1.  
    1. Tout d’abord, vous devez créer votre SPTrustedIdentityTokenIssuer, une partie de confiance dans ADFS, ainsi qu’une application Web et une collection de sites SharePoint.  Assurez-vous que vous pouvez ouvrir une session sur le site avec vos informations d’identification ADFS.  Des détails approfondis sur la façon de procéder sont fournis dans l’un de mes billets précédents à la page http://blogs.msdn.com/b/sharepoint_fr/archive/2010/11/24/configuration-de-sharepoint-2010-et-d-adfs-v2-de-bout-en-bout.aspx.

2.       Ouvrez la page Access Control Management.

  1.  
    1. Ouvrez une session sur votre portail de gestion Windows Azure. Cliquez sur le menu Service Bus, Access Control et Caching dans le volet gauche. Cliquez sur Access Control dans la partie supérieure du volet gauche (sous AppFabric), cliquez sur votre espace de noms dans le volet droit, puis cliquez sur le bouton Access Control Service dans la partie Manage du Ruban.  La page Access Control Service s’affiche alors à l’écran.

3.       Créez une approbation entre ADFS et ACS.

  1.  
    1. Au cours de cette étape, nous allons configurer ACS en tant que fournisseur d’identités dans ADFS.  Pour commencer, accédez à votre serveur ADFS et ouvrez la console de gestion AD FS 2.0.
    2. Accédez au nœud AD FS 2.0…Trust Relationships…Claims Provider Trusts, puis cliquez sur le lien Add Claims Provider Trust… dans le volet gauche.
    3. Cliquez sur le bouton Start pour lancer l’Assistant.
    4. Utilisez l’option par défaut pour importer des données sur la partie de confiance publiée en ligne. L’URL que vous devez utiliser se trouve sur le portail de gestion ACS.  Revenez dans votre navigateur où le portail est ouvert, puis cliquez sur le lien Application Integration sous le menu Trust relationships dans le volet gauche.
    5. Copiez l’URL affichée pour les métadonnées WS-Federation et collez-la dans l’adresse des métadonnées de fédération (nom d’hôte ou URL) : modifiez la zone dans l’Assistant ADFS, puis cliquez sur le bouton Next.
    6. Tapez un nom complet et éventuellement des remarques, puis cliquez sur le bouton Next.
    7. Maintenez l’option par défaut qui autorise tous les utilisateurs à accéder au fournisseur d’identités, puis cliquez sur le bouton Next.
    8. Cliquez sur le bouton Next de façon à créer le fournisseur d’identités, puis laissez la case à cocher activée pour ouvrir la boîte de dialogue de l’édition de règles.  La suite de cette section va être très similaire à ce que j’ai décrit dans le billet http://blogs.technet.com/b/speschka/archive/2010/11/24/configuring-adfs-trusts-for-multiple-identity-providers-with-sharepoint-2010.aspx à propos de la définition d’une approbation entre deux serveurs ADFS :

Vous devez créer des règles pour communiquer toutes les revendications que vous obtenez du serveur ADFS IP.  Ainsi, dans la boîte de dialogue des règles, pour chacune des revendications que vous souhaitez envoyer à SharePoint, vous allez procéder comme suit :

  1. Cliquez sur Add Rule.
  2. Sélectionnez Pass Through ou Filter an Incoming Claim dans la liste déroulante Claim Rule Template, puis cliquez sur le bouton Next.
  3. Attribuez un nom à la revendication - il serait probablement judicieux d’inclure le nom de la revendication transmise.  Pour la liste déroulante Incoming Claim Type, sélectionnez le type de la revendication que vous souhaitez transmettre, par exemple, E-Mail Address. En règle générale, je laisse l’option par défaut activée pour Pass through all claim values, mais si vous possédez différentes règles métiers, sélectionnez la ou les options appropriées, puis cliquez sur le bouton Finish. Notez que si vous choisissez de transmettre toutes les valeurs de revendication, une boîte de dialogue d’avertissement s’affiche dans ADFS.

Une fois que vous avez ajouté les revendications à transmettre, pour chaque revendication dont vous avez besoin dans SharePoint, vous pouvez fermer la boîte de dialogue de règles.  À présent, pour la dernière étape de configuration d’ADFS, vous devez rechercher la partie de confiance SharePoint. Cliquez sur la boîte de dialogue Edit Claim Rules puis, pour chaque règle de transmission de revendication que vous avez définie à l’étape précédente, vous devez AUSSI ajouter une règle de transmission de revendication pour la partie de confiance SharePoint. C’est ce qui permettra aux revendications de transiter d’ACS à ADFS via le fournisseur de revendications approuvé, puis de la partie de confiance approuvée vers SharePoint.

Votre configuration d’ADFS est maintenant terminée.

4.       Ajoutez ADFS en tant que partie de confiance dans ACS.

  1.  
    1. Revenez dans votre navigateur où le portail est ouvert, puis cliquez sur le lien Relying party applications sous le menu Trust relationships dans le volet gauche.
    2. Cliquez sur Add link.
    3. Complétez la section Relying Party Application Settings.
      1.  Entrez un nom complet, tel que « ADFS vers ACS ».
      2. Utilisez le mode par défaut ou entrez les paramètres manuellement.
      3. Dans la zone d’édition Realm, vous devez entrer le domaine qui sera envoyé avec la demande par ADFS. Il s’avère qu’il existe une liste spécifique de domaines dans ADFS qui est envoyée en cas de redirection vers un autre fournisseur d’identités. Autrement dit, vous N’UTILISEZ PAS le domaine qui a été utilisé lors de la création de SPTrustedIdentityTokenIssuer dans SharePoint. À la place, je recommande d’utiliser http://NomDeVotreServerAdfsComplet/adfs/services/trust.
      4. En guise d’URL de retour, utilisez https:// NomDeVotreServerAdfsComplet /adfs/ls/.
      5. La liste déroulante du format de jeton peut indiquer SAML 2.0 ou 1.1.  Étant donné que le jeton est envoyé à ADFS et non à SharePoint et que ADFS prend en charge les jetons SAML 2.0, vous n’avez pas besoin de sélectionner SAML 1.1 comme l’exigerait une connexion directe à SharePoint.
      6. Vous pouvez attribuer au jeton la durée de vie (en secondes) de votre choix.  Par défaut, elle est de 10 minutes ; j’ai fixé la mienne à 3 600, soit 1 heure.
    4. Complétez la section Authentication Settings.
      1. En ce qui concerne les fournisseurs d’identités, vous pouvez les sélectionner tous, à moins que vous ayez ajouté antérieurement le même serveur ADFS qu’un fournisseur d’identités (ce qu’il est le cas si vous avez suivi la procédure décrite dans le premier billet de la série). Auquel cas, vous pouvez tout cocher à l’exception du fournisseur d’identités qui renvoie vers le même serveur ADFS que vous définissez maintenant comme partie de confiance.
      2. Sous Rule groups, pour gagner du temps, je vous suggère de suivre les conseils que je vous ai donnés dans la 1ère partie à propos des groupes de règles, ou si vous avez terminé la 1ère partie, sélectionnez simplement ce groupe de règles dans la liste.
    5. Dans Token Signing Settings, vous pouvez laisser l’option par défaut sélectionnée, à savoir, Use service namespace certificate (standard).

Cliquez sur le bouton Save pour enregistrer vos modifications et créer la partie de confiance. 

Vous devriez maintenant être en mesure d’ouvrir une session sur votre site SharePoint en utilisant ADFS ou ACS. Ne perdez toutefois pas de vue que ADFS écrira un cookie pour se rappeler du fournisseur d’identités que vous avez utilisé en dernier. Dès lors, vous ne serez plus invité à désigner le fournisseur d’identités, à moins que vous n’utilisiez la fenêtre de navigation InPrivate dans Internet Explorer (je grossis exagérément ce texte, car ce point est souvent omis et est source de confusion). Par exemple, voici l’écran que vous obtenez la première fois que vous être redirigé vers le serveur ADFS ou si vous utilisez une session de navigation InPrivate :

Pour le reste, ce qui est indiqué dans la 1ère partie de cette série s’applique ici (y compris la mise en garde à propos de l’utilisation d’une adresse de messagerie comme Windows Live ID). Je ne publierai donc pas à nouveau de captures d’écran puisqu’elles sont quasiment identiques. C’est ainsi que se termine cette série. Vous devez maintenant être en mesure d’intégrer avec succès ADFS, ACS et tous les fournisseurs d’identités pris en charge par ACS dans votre environnement SharePoint 2010. 

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 2