Authentification SAML fédérée avec SharePoint 2010 et le service de contrôle d’accès Azure (ACS) partie 1

Article
06/27/2011

Article d’origine publié le vendredi 6 mai 2011

REMARQUE : comme d’habitude, la mise en forme de ce site laisse à désirer. Je vous recommande de télécharger le document Word joint à cet article pour une lecture plus confortable.

Je me suis récemment intéressé aux services ACS (Azure Access Control Service) et à ses différentes options d’intégration. Beaucoup de discussions concernent l’authentification basée sur les revendications avec SharePoint 2010, et comment intégrer Windows Live, Facebook, etc. Les services ACS (également connus sous le nom d’AppFabric ACS chez les puristes Azure / spécialistes du marketing) sont très pratiques car ils incluent des « connecteurs » pour ces fournisseurs d’identité courants prêts à l’emploi. Lorsque vous établissez un espace de noms ACS (qu’on peut décrire comme un compte avec des connecteurs et des paramètres de configuration), vous simplifiez et rationalisez la connectivité à ADFS 2.0, Windows Live, Yahoo, Google et Facebook. Le programmeur un peu paresseux que je suis se dit qu’il y a certainement quelque chose à en tirer et j’ai décidé de m’y intéresser sous différents angles. Je vais en décrire un premier aspect dans cet article.

Pour ce scénario, je souhaitais principalement établir une relation d’approbation directe entre SharePoint 2010 et ACS. Je voudrais 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 les réseaux sociaux ne m’intéressent pas vraiment (ce blog constitue mon engagement maximal à cet égard ), je n’ai pas de compte Facebook ou Twitter car je ne vois pas de réel intérêt à 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, créer un espace de noms ACS, comment gérer ACS, etc., les spécialistes de Windows Azure ont déjà diffusé beaucoup d’informations à ce sujet.

Je vais décrire le processus de définition des approbations, des certificats et de la configuration nécessaires pour assurer le bon fonctionnement de l’ensemble. À la fin, je vais inclure certaines copies d’écran de mon poste de travail connecté avec des identités de chacun de ces fournisseurs. Voici comment se connecter :

Ouvrez la page Access Control Management
1. Connectez-vous à votre portail de gestion Windows Azure. Cliquez sur Service Bus, Access Control et le menu Caching dans le volet gauche. Cliquez sur Access Control en haut du gauche de 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 Management s’ouvre.
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. La case d’option WS-Federation identity provider doit être activée par défaut ; sinon, activez-la. Il le faut pour utiliser 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 Internet, vous indiquez simplement l’URL donnant accès au point de terminaison des métadonnées de fédération. Par défaut il s’agit de https://yourAdfsServer.com/FederationMetadata/2007-06/FederationMetadata.xml. Si votre serveur ADFS n’est pas exposé à Internet, ouvrez l’URL 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 la case d’option 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 en somme tout ce qu’il y a à faire pour créer un fournisseur d’identité dans ACS.

3. Ajouter une partie de confiance pour SharePoint

1. Maintenant vous devez ajouter SharePoint comme 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. Entrez 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 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 réglée sur SAML 1.1
  6. Vous pouvez définir la durée de vie du jeton (secs) à la valeur souhaitée. Celle-ci est de 10 minutes par défaut ; je choisis 3600, donc 1 heure.
4. Remplissez la section Authentication Settings
  1. Cochez chaque case sous Identity providers ; le fournisseur d’identité ADFS que vous avez créé à l’étape précédente doit s’y trouver
  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

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

1. Je suppose 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, dans l’étape précédente il fallait activer une case en regard du ou des groupes que vous souhaitez utiliser avec la partie de confiance au lieu de prendre la valeur par défaut 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 type « 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. La procédure la plus simple à ce stade consiste à cliquer sur le lien Generate. Il va automatiquement créer un ensemble de règles qui énumèrent toutes les revendications que vous obtenez de chaque fournisseur d’identité, puis crée une règle pour chacune qui passe la valeur de revendication avec le même type de revendication à la partie de confiance
4. Dans la page Generate Rules, activez simplement la case en regard de chaque fournisseur d’identité et cliquez sur le bouton Generate. Ceci crée les règles que j’ai décrites précédemment. Vous êtes ensuite redirigé vers la page Edit Rule Group, où vous verrez toutes les règles répertoriées. Dans de nombreux cas, cela suffit , mais nous devons toutefois tenir compte d’une anomalie. Dans SharePoint, nous allons utiliser l’adresse électronique comme revendication d’identité. Ironiquement, tous les fournisseurs d’identité envoient l’adresse électronique (et j’ai créé des règles en ce sens) sauf pour Windows Live. Ainsi, pour cet exemple, je vais feindre la pièce Windows Live. Je veux dire que je vais prendre la revendication qu’il fournit (nameidentifier) et je vais créer une règle qui la repasse, mais la repasse sous la forme d’une revendication par courrier électronique. Cette intervention assure simplement 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, sélectionnez Windows Live I
7. Dans la section Input claim, cliquez sur la case d’option 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 la case d’option en regard de Select type :
9. Dans la liste déroulante, recherchez https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress et sélectionnez cette option
10. Entrez une description, 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 devez en obtenir des informations supplémentaires lors de la création et de la configuration d’autres composants.

5. 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 approbation 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 et cliquez sur le lien Add Relying Party Trust… dans le volet droit
3. Cliquez sur le bouton Start pour démarrer l’Assistant
4. Utilisez l’option par défaut pour importer des données sur la partie de confiance publiées en ligne. L’URL que vous devez utiliser se trouve dans le portail de gestion ACS. Revenez à votre navigateur dans lequel le portail est ouvert, puis cliquez sur le lien Application Integration sous le menu Trust relationships dans le volet gauche
5. Copiez l’URL qu’il indique pour les métadonnées WS-Federation, et collez-la dans la zone d’édition Federation Metadata address (nom d’hôte ou URL) : dans l’assistant ADFS, puis cliquez sur le bouton Next
6. Tapez un nom d’affichage et éventuellement des notes, puis cliquez sur le bouton Next
7. Laissez l’option par défaut permettant aux utilisateurs d’accéder à la partie de confiance, puis cliquez sur le bouton Next
8. Cliquez sur le bouton Next afin qu’il crée la partie de confiance
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é, puis cliquez sur le bouton Next.
12. Remplissez 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 Director
  3. Dans la section Mapping of LDAP, 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.

6. Configurer l’approbation 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 s’affichera 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) :

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

Copiez les données de l’élément X509Certificate et collez-les dans le bloc-notes. Enregistrez-les avec une extension .CER (le codage doit être ANSI) ; pour 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 approuvées dans SharePoint. Pour ce faire, suivez les instructions à l’adresse https://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 :

$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 cette intervention à plusieurs endroits ; vous pouvez utiliser https://blogs.msdn.com/b/sharepoint_fr/archive/2010/11/24/configuration-de-sharepoint-2010-et-d-adfs-v2-de-bout-en-bout.aspx comme point de départ (faites simplement défiler le texte jusqu’aux informations venant APRÈS la configuration d’ADFS). Quelques rappels :
  1. 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 utilisable pour votre revendication d’identité. Je recommande plutôt de revenir simplement à l’adresse électronique et d’ajouter les règles appropriées dans ACS de la manière décrite ci-dessus
  2. Le paramètre SignInUrl pour New-SPTrustedIdentityTokenIssuer doigt pointer vers votre instance ACS. Par exemple, https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation. Vous pouvez trouver cette information 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 de la liaison POST (ce doit être la seule à cet endroit).
2. La dernière étape consiste à créer votre application Web, à la configurer pour utiliser une 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. Rappelons que vous devez configurer l’administrateur de la collection de sites avec l’une des adresses électroniques 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 électroniques ou des revendications de rôles aux groupes SharePoint comme vous le feriez normalement.

Mais il ne faut pas oublier le problème actuellement lié à Windows Live ID. Comme nous l’avons indiqué précédemment dans cet article, vous n’avez pas réellement une adresse électronique valide pour Windows Live, vous devrez donc ajouter ce qui est qualifié de 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 normalement avoir terminé. Je n’ai même pas vérifié les options de répertoire qui sont éventuellement disponibles pour Windows Live ID (j’imagine probablement aucune). Mais c’est un départ permettant de poursuivre cette validation de concept. Maintenant, nous pouvons voir à quoi ressemble une connexion à mon site en utilisant chacun de ces fournisseurs d’identité :

Page de connexion

ADFS

Google

Yahoo

Windows Live ID

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 1

Authentification SAML fédérée avec SharePoint 2010 et le service de contrôle d’accès Azure (ACS) partie 1

Additional resources