Traduction

Cet article est la traduction la plus fidèle possible de l'article original de Steve Peschka, Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1.

Authentification SAML fédérée avec SharePoint 2010 et Azure Access Control Service - Partie 1

Depuis tout récemment, je regardais Windows Azure Access Control Service (ACS) avec l'œil d'un intéressé, en pensant à quelques-unes de ses différentes options d'intégration. Il y a tout le temps beaucoup de papotage au sujet de l'authentification basée sur les revendications avec SharePoint 2010, et comment intégrer ADFS, Windows Live, Facebook, etc. ACS (aussi connu comme AppFabric ACS chez les puristes Azure / spécialistes du marketing d'Azure) est plutôt cool, car il inclue des « connecteurs » pour ces fournisseurs d'identité courants prêts à l'emploi. Lorsque vous établissez un espace de noms ACS (considérez-le comme un compte avec des connecteurs et des paramètres de configuration), vous disposez d'une connectivité simplifiée et rationalisée à ADFS 2.0, Windows Live, Yahoo, Google et Facebook. Le coté programmeur paresseux en moi se dit qu'il y a certainement quelque chose qui se trame, ainsi j'ai décidé de me pencher dessus sous différents angles. Je vais en décrire un premier dans cet article.

Pour ce scénario, je tenais simplement à établir une confiance directe entre SharePoint 2010 et ACS. Je voulais pouvoir utiliser des comptes ADFS, Windows Live, Yahoo et Google pour m'authentifier et accéder à mon site SharePoint. Je n'ai pas inclus Facebook, car l'informatique sociale n'est pas vraiment mon truc (mon blog est ce qui se rapproche le plus de cette activité), je n'ai donc pas de compte Facebook ou Twitter, car je ne suis pas réellement intéressé à fréquemment partager à grande échelle des informations souvent inutiles (« Puffy vient d'avoir trois chatons - adorables !! »). Je ne vais PAS expliquer comment obtenir un compte Windows Azure, comment créer un espace de noms Access Control Service, comment gérer ACS, etc. - il devrait y avoir des tonnes d'infos de la part des spécialistes de Windows Azure qui ont déjà été diffusées à ce sujet, donc je ne vais pas essayer de réinventer cette roue.

Ce que je vais décrire est le processus de définition des divers approbations, des certificats et de la configuration nécessaires pour assurer le bon fonctionnement de cet ensemble. À la fin, je vais inclure quelques copies d'écran de mon poste me montrant comme connecté avec des identités de chacun de ces fournisseurs. Voici les étapes pour se connecter :

Ouvrez la page « Access Control Management »

Connectez-vous à votre portail de gestion Windows Azure. Cliquez sur le menu « Service Bus, Access Control and Caching » dans le volet gauche. Cliquez sur « Access Control » en haut 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. Cela va ouvrir la page « Access Control Management ».

Ajout d'un fournisseur d'identité pour ADFS

  1. Cliquez sur « Identity providers » dans le menu « Trust relationships » du volet gauche.
  2. Cliquez sur le lien « Add ».
  3. Le bouton radio « WS-Federation identity provider » devrait être activé par défaut ; activez-le s'il ne l'est pas. C'est ce qui est utilisé pour ADFS 2.0. Cliquez sur le bouton « Next ».
  4. Remplissez la section « Identity Provider Settings » :
    1. Remplissez le nom d'affichage, par exemple « Mon serveur ADFS ».
    2. Pour les métadonnées WS-Federation, si votre serveur ADFS est exposé via l'Internet, vous indiquez alors simplement l'URL pour accéder au point de terminaison des métadonnées de fédération. Par défaut il est localisé à https://votreServeurAdfs.com/FederationMetadata/2007-06/FederationMetadata.xml. Si votre serveur ADFS n'est pas exposé à l'Internet, alors ouvrez l'URL donnant accès au point de terminaison dans votre navigateur local. Accédez à votre navigateur et enregistrez la page dans le système de fichiers local sous la forme d'un fichier .XML. Ensuite, sous « Identity Provider Settings » dans ACS, cliquez sur le bouton radio en regard de la zone d'édition « File », puis utilisez le bouton « Browse » pour trouver le fichier xml de métadonnées de fédération que vous venez d'enregistrer.

C'est à peu près tout ce qu'il y a à faire pour créer un fournisseur d'identité dans ACS.

Ajouter une partie de confiance pour SharePoint

  1. Maintenant vous devez ajouter SharePoint en tant que partie de confiance d'ACS, comme vous le faites lorsque vous configurez SharePoint et ADFS ensemble. Commencez en cliquant sur le lien « Relying party applications » sous le menu « Trust relationships » dans le volet gauche.
  2. Cliquez sur le lien « Add ».
  3. Remplissez la section « Relying Party Application Settings » :
    1. Saisissez un nom d'affichage, tel que « SharePoint 2010 ».
    2. Utilisez le mode par défaut d'entrée manuelle des paramètres, « Enter settings manually ».
    3. Dans la zone d'édition « Realm », entrez un domaine, puis enregistrez cette information, car vous l'utiliserez de nouveau lors de la création de SPTrustedIdentityTokenIssuer dans SharePoint. Pour les besoins de cet exemple, supposons que le domaine est « urn:sharepoint:acs ».
    4. Pour l'URL de retour, utilisez le même format que lors de la définition de SharePoint comme partie de confiance dans ADFS:  https://yourSiteName/_trust/.
    5. La liste déroulante « Token format » doit être sélectionnée à SAML 1.1.
    6. Vous pouvez définir la durée de vie du jeton, « Token lifetime (secs) », à la valeur souhaitée. Celle-ci est de 10 minutes par défaut ; je définis le mien à 3600, c'est-à-dire 1 heure.
  4. Remplissez la section « Authentication Settings » :
    1. Cochez chaque case sous « Identity providers » ; elle devrait vous afficher le fournisseur d'identité ADFS que vous avez créé à l'étape précédente.
    2. Sous « Rule groups », laissez l'option par défaut activée, à savoir « Create new rule group ».
  5. Dans « Token Signing Settings », vous pouvez laisser l'option par défaut sélectionnée, à savoir « Use service namespace certificate (standard) ».
  6. Cliquez sur le bouton « Save » pour enregistrer vos modifications et créer la partie de confiance.

Créer les règles pour la partie de confiance

  1. Je vais supposer ici que vous n'avez pas encore créé un ensemble de règles dans ACS, nous allons donc en créer un nouveau groupe. Si vous souhaitiez réutiliser un groupe dont vous disposiez, dans l'étape précédente il fallait activer une case en regard du(des) groupe(s) que vous souhaitez utiliser avec la partie de confiance au lieu de prendre la valeur par défaut de l'action « Create new rule group ». Mais puisque nous en créons un nouveau, cliquez sur le lien « Rule groups » sous le menu « Trust relationships » dans le volet gauche.
  2. Vous devriez voir un groupe de règles portant un nom du genre « Groupe de règles par défaut pour le nom de votre partie de confiance ». Cliquez sur ce lien pour ce nom de groupe de règles.
  3. Vraiment, la chose la plus simple à faire à ce stade consiste à cliquer sur le lien « Generate ». Il va automatiquement vous créer un ensemble de règles qui fondamentalement énumèrent toutes les revendications que vous allez obtenir de chaque fournisseur d'identité, puis crée une règle pour chacune qui transmet la valeur de revendication avec le même type de revendication à la partie de confiance.
  4. Dans la page « Generate Rules », cochez simplement la case en regard de chaque fournisseur d'identité et cliquez sur le bouton « Generate ». Ceci crée les règles comme je l'ai décrit précédemment. Une fois terminée, vous êtes ensuite redirigé vers la page « Edit Rule Group », où vous verrez toutes les règles listées. Dans de nombreux cas, cela devrait suffire, mais nous avons toutefois une anomalie dont nous devons tenir compte ici. Dans SharePoint, nous allons utiliser l'adresse e-mail comme revendication d'identité. Ironiquement, tous les fournisseurs d'identité envoient l'adresse e-mail (et ont des règles créées en ce sens) sauf pour Windows Live. Ainsi, pour cet exemple, je vais feindre la partie Windows Live. Ce que je veux dire par là est que je vais prendre la revendication qu'il fournit - nameidentifier - et je vais créer une règle qui la repasse, mais qui va la repasser sous la forme d'une revendication par e-mail. Ce n'est pas le moment de haïr Steve, c'est simplement une façon d'assurer le bon fonctionnement de l'environnement de démonstration avec le moins de « pièces mobiles » possibles (et il y en a déjà plusieurs ). Je vais maintenant ajouter la règle finale.
  5. Cliquez sur le lien « Add ».
  6. Dans la liste déroulante « Identity Provider », sélectionnez Windows Live ID.
  7. Dans la section « Input claim », cliquez sur le bouton radio en regard de « Select type : ». Windows Live ID ne prend en charge que ce type de revendication et celui-ci est donc déjà sélectionné (nameidentifier).
  8. Faites défiler les informations jusqu'à la section « Output claim type » et cliquez sur le bouton radio en regard de « Select type : ».
  9. Dans la liste déroulante, recherchez et sélectionnez « http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress ».
  10. Entrez une description si vous voulez, puis cliquez sur le bouton « Save » pour enregistrer vos modifications et créer la règle.
  11. Vous serez redirigé vers la page « Edit Rule Group », puis cliquez sur le bouton « Save » pour enregistrer toutes vos modifications. Vous avez maintenant terminé la configuration ACS, mais ne fermez pas encore le navigateur, car vous allez devoir y obtenir des informations supplémentaires lors de la création et de la configuration des autres composants.

Créer une partie de confiance pour ACS dans ADFS

  1. Alors qu'ADFS est un fournisseur d'identité à ACS, ACS est la partie de confiance pour ADFS. Cela signifie que nous devons configurer une partie de confiance dans ADFS afin que lorsque ACS redirige une demande d'authentification à ADFS, une confiance a été établie qui permet à ADFS de répondre. Commencez par accéder à votre serveur ADFS et ouvrir la console de gestion AD FS 2.0.
  2. Accédez au nœud « AD FS 2.0…Trust Relationships…Relying Party Trusts » et cliquez sur le lien « Add Relying Party Trust… » dans le volet droit.
  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 dans 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 qui est affichée pour les métadonnées WS-Federation, et collez-la dans la zone d'édition « Federation Metadata address (host name or URL) : » dans l'assistant ADFS, puis cliquez sur le bouton « Next ».
  6. Saisissez un nom d'affichage et éventuellement quelques notes, puis cliquez sur le bouton « Next ».
  7. Laissez l'option par défaut permettant à tous les utilisateurs d'accéder à la partie de confiance, et cliquez sur le bouton « Next ».
  8. Cliquez sur le bouton « Next » afin que la partie de confiance soit créée.
  9. Une fois la partie de confiance créée, vous ouvrez « Rules Editor » dans ADFS pour créer de nouvelles règles pour passer les valeurs de revendication à ACS.
  10. L'onglet « Issuance Transform Rules » étant sélectionné, cliquez sur le bouton « Add Rule… ».
  11. Laissez le modèle par défaut « Send LDAP Attributes as Claims » sélectionné, et cliquez sur le bouton « Next ».
  12. Complétez le reste des détails de la règle :
    1. Tapez un nom de règle de revendication.
    2. Dans la liste déroulante « Attribute store : », sélectionnez « Active Directory ».
    3. Dans la section « Mapping of LDAP attributes », mappez
      1. « LDAP attribute E-Mail-Addresses » à « Outgoing Claim Type E-Mail Address ».
      2. « LDAP attribute Token-Groups - Unqualified Names » à « Outgoing Claim Type Role ».
    4. Cliquez sur le bouton « Finish » pour enregistrer votre règle. La configuration ADFS est maintenant terminée.

Configurer la confiance SharePoint avec ACS

    1. C'est un processus à plusieurs étapes qui commence par l'obtention du certificat de signature de jetons d'ACS. Heureusement le certificat est inclus dans le fichier FederationMetadata.xml, nous allons donc l'y récupérer et l'enregistrer localement dans le serveur SharePoint. Sur le serveur SharePoint, ouvrez un navigateur et ouvrez la page « Access Control Management » comme décrit ci-dessus.
    2. Cliquez sur le lien « Application Integration » sous le menu « Trust relationships » dans le volet gauche, copiez l'URL qu'il indique pour les métadonnées WS-Federation et collez-la dans votre navigateur. Le fichier ACS FederationMetadata.xml sera affiché dans le navigateur.
    3. Trouvez la section ressemblant à ce qui suit (c'est environ la deuxième grande section à partir du haut de la page) :
    4.  
      Sélectionnez
      <RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
      
      <KeyDescriptor use="signing">
      
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      
      <X509Data>
      
      <X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>
      
      </X509Data>
      

      Copiez les données de l'élément X509Certificate et collez-les dans le Bloc-notes. Enregistrez-les dans un fichier avec une extension .CER (le codage doit être ANSI) ; pour les besoins de cet article, supposons que vous nommez le fichier C:\AcsTokenSigning.cer. C'est le certificat de signature de jetons pour ACS.
    1. Ajoutez le certificat de signature de jetons ACS à la liste des autorités racine de confiance dans SharePoint. Vous pouvez effectuer cela comme décrite à l'adresse http://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx ou vous pouvez l'ajouter avec PowerShell comme ceci :
     
    Sélectionnez
    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\AcsTokenSigning.cer")
    
    New-SPTrustedRootAuthority -Name "ACS Token Signing" -Certificate $cert
    
    1. L'étape suivante consiste à créer votre nouveau SPTrustedIdentityTokenIssuer. J'ai décrit cela à plusieurs endroits ; vous pouvez utiliser comme point de départ (faites simplement défiler le texte jusqu'aux informations venant APRÈS la configuration d'ADFS). Quelques points a se rappeler :
      1. À la fois name et nameidentifier sont des types de revendication réservés dans SharePoint, donc même si nameidentifier est la seule revendication commune entre les fournisseurs d'identité standard dans ACS, elle n'est pas une option dans le cadre de votre revendication d'identité. Je recommande, pour l'instant, plutôt de revenir simplement à l'adresse e-mail et d'ajouter les règles appropriées dans ACS de la manière que je l'ai décrite ci-dessus.
      2. Le paramètre SignInUrl pour New-SPTrustedIdentityTokenIssuer devrait pointer vers votre instance ACS. Par exemple, https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation. Vous pouvez trouver cela en recherchant la partie de confiance que vous avez définie dans ADFS pour ACS. Ouvrez la boîte de dialogue des propriétés de la partie de confiance, cliquez sur l'onglet « Endpoints », et utilisez l'URL qu'il affiche pour « WS-Federation Passive Endpoint » pour la liaison POST (ce devrait être la seule à cet endroit).
    2. La dernière étape consiste à créer votre application Web, à la configurer pour utiliser l'authentification basée sur les revendications et le SPTrustedIdentityTokenIssuer que vous avez créé pour ACS, et enfin à créer une collection de sites dans l'application Web et à commencer les tests.

À ce stade vous devriez être prêt à accéder au site et à l'essayer. Rappelez-vous que vous allez devoir configurer l'administrateur de la collection de sites pour être l'une des adresses e-mail que l'un des fournisseurs d'identité renverra afin que vous puissiez vous connecter au site. Une fois que vous y êtes, vous pouvez ajouter des adresses e-mail ou des revendications de rôles aux groupes SharePoint comme vous le feriez normalement.

La mise en garde à se rappeler une nouvelle fois, pour le moment, concerne Windows Live ID. Comme nous l'avons indiqué précédemment dans cet article, vous n'aurez pas réellement une adresse e-mail valide pour Windows Live, vous devrez donc ajouter ce qu'ils appellent un PUID à votre groupe SharePoint. À des fins de test, la manière la plus simple de le faire consiste à se connecter en utilisant Windows Live ID, vous accéderez ensuite à la page dans SharePoint qui indique que vous êtes connecté en tant que « foo » et l'accès est refusé. À partir de là, vous pouvez copier le PUID, vous connecter en tant qu'utilisateur administrateur, ajouter le PUID à un groupe SharePoint et vous devriez avoir terminé. Je n'ai même pas vérifié quels genres d'options de répertoire qui sont éventuellement disponibles pour Windows Live ID (j'imagine probablement aucune). Mais c'est un départ, de sorte que nous puissions poursuivre cette validation de concept. À présent que tout ça est fait, voici à quoi ressemble de se connecter à mon site en utilisant chacun de ces fournisseurs d'identité :

Page de connexion

Image non disponible

ADFS

Image non disponible

Google

Image non disponible

Yahoo

Image non disponible

Windows Live ID

Image non disponible

Conclusion

Dans cette première partie de la série, j'ai décrit comment configurer SharePoint de façon à établir une confiance directement auprès du service Azure Access Control (ACS) et l'utiliser afin de fédérer l'authentification entre ADFS, Yahoo, Google et Windows Live pour vous et enfin utiliser cela pour accéder à SharePoint. Nous avons vu le processus de définition des approbations, des certificats et de la configuration nécessaires pour assurer le bon fonctionnement de l'ensemble dans le cadre de la mise en place d'une authentification SAML fédérée avec SharePoint 2010 et Windows Azure Access Control Service (ACS).

Dans la deuxième partie, nous allons partir d'un scénario similaire à la différence près que son implémentation réelle sera inversée par rapport à la première partie.

Liens

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.