Enfin un moyen pratique de fédérer avec Windows Live et SharePoint 2010 en utilisant OAuth et SAML

  • Article

Article d’origine publié le jeudi 1er mars 2012

Beaucoup de personnes m’ont parlé par le passé de la fédération SharePoint avec Windows Live. En surface, cela semble une très bonne idée – Windows Live a des millions d’utilisateurs, chacun s’y connecte avec son adresse de messagerie, ce que nous utilisons beaucoup comme revendication d’identité, c’est un service très évolutif avec diverses instructions sur la façon de procéder – soit directement soit via ACS (Access Control Service). Alors, pourquoi suis-je réticent à l’utiliser avec SharePoint ? Eh bien, pour ceux d’entre vous qui ont déjà essayé, vous savez de quoi je parle – lorsque vous fédérez avec Windows Live, vous n’obtenez jamais en retour l’adresse de messagerie d’un utilisateur comme une revendication. Tout ce que vous obtenez, c’est un identificateur spécial Windows Live, appelé PUID. Autant que je sache, PUID signifie Practically GUID (Pratiquement GUID), parce que ça y ressemble beaucoup et c’est tout aussi utile.

Par exemple, si vous fédérez avec Windows Live, comment ajouter quelqu’un à un site ? Il vous faut son PUID, puis ajouter ce PUID à un groupe SharePoint ou à un niveau d’autorisation. Sérieusement, connaissez-vous quelqu’un qui connaisse son PUID (si vous-même le connaissez, vous avez certainement mieux à faire de votre temps libre). Même si, par miracle, il se trouve que vous connaissez votre PUID, dans quelle mesure sert-il pour accorder à des utilisateurs des droits à différentes collections de sites ? Pensez-vous vraiment que quelqu’un d’autre pourrait vous choisir dans une queue de PUID (ou dans un sélecteur de personnes, le cas échéant) ? Bien sûr que non ! Et donc ma frustration à ce sujet s’amplifie !

J’ai pensé que nous pourrions nous pencher sur une solution plus utopique avec ACS. ACS est vraiment génial en termes de fourniture de connecteurs prêts à l’emploi vers plusieurs fournisseurs d’identités comme Windows Live, Google, Yahoo et Facebook. Avec Facebook, il y a même quelques soupçons de magie en plus puisque OAuth est utilisé pour l’authentification et qu’un ensemble de revendications SAML est retourné. Vraiment cool ! Alors pourquoi ne font-ils pas pareil avec Windows Live ? Windows Live prend désormais en charge OAuth alors il semble qu’une opportunité en la matière pourrait finalement voir le jour. Mais en dépit de nos espérances, l’équipe ACS ne vole pas à notre secours. C’est là l’objet de ce préambule et j’ai finalement décidé d’écrire moi-même un billet à ce sujet.

Pourquoi nous intéressons-nous à OAuth ? Eh bien, contrairement au PUID que vous obtenez en fédérant directement avec Windows Live, la prise en charge d’OAuth dans Windows Live vous permet d’obtenir beaucoup plus d’informations sur l’utilisateur, y compris son adresse de messagerie. Le plan d’attaque se résume essentiellement comme suit :

  1. Écrire un fournisseur d’identités personnalisé en utilisant Windows Identity Foundation (WIF).
  2. Lorsqu’une personne est redirigée vers notre STS, si elle ne s’est pas déjà authentifiée, nous la redirigeons à nouveau vers Windows Live. Vous devez créer une « application » avec Windows Live pour procéder ainsi, mais je l’expliquerai plus en détail ultérieurement.
  3. Une fois authentifiée, la personne est redirigée vers le STS personnalisé et, lorsqu’elle revient, la chaîne de requête inclut un jeton de connexion qui peut être échangé contre un jeton d’accès.
  4. Le STS fait ensuite une autre requête à Windows Live avec le code de connexion et demande un jeton d’accès.
  5. Lorsqu’il obtient le jeton d’accès, il fait une requête finale à Windows Live avec le jeton d’accès en demandant des informations de base sur l’utilisateur (j’expliquerai ultérieurement ce qui est obtenu).
  6. Une fois obtenues les informations sur l’utilisateur auprès de Windows Live, nous utilisons notre STS personnalisé pour créer un ensemble de revendications SAML pour l’utilisateur et les remplir avec les informations sur l’utilisateur. Puis, nous redirigeons vers l’application quelle qu’elle soit ayant demandé l’authentification au départ pour la laisser utiliser les jetons SAML comme elle l’entend. Dans ce cas particulier, j’ai testé mon STS avec une application ASP.NET standard et avec une application Web SharePoint 2010.

Tout le code source est joint à ce billet, mais un peu de configuration reste à faire, et il vous faudra recompiler l’application avec l’ID et le secret obtenus auprès de Windows Live, mais à part ce copier-coller il n’y a en réalité aucun code à écrire pour le faire fonctionner. Maintenant, voyons en détail tout ce dont vous avez besoin pour l’utiliser.

Créer un certificat de signature de jetons

Vous devrez créer un certificat à utiliser pour signer vos jetons SAML. Le certificat utilisé pour signer les certificats n’a rien de spécial, hormis le fait de vous assurer que vous avez sa clé privée. Dans mon cas, les services de certificats sont installés sur mon domaine, il m’a donc suffit d’ouvrir le Gestionnaire des services Internet (IIS) et de sélectionner l’option pour créer un certificat de domaine. J’ai suivi l’assistant et j’ai aussitôt obtenu un nouveau certificat complet avec clé privée. Pour ce projet, j’ai créé un certificat appelé livevbtoys.

Comme je vais l’expliquer dans la prochaine section, lorsque des requêtes arrivent initialement chez le STS, l’utilisateur est anonyme. Pour utiliser ce certificat afin de signer les jetons SAML, vous devez accorder au processus IIS l’accès à la clé privée de ce certificat. Lorsque une requête arrive, l’identité du processus IIS est Service réseau. Pour lui accorder les droits pour la clé, vous devez :

  1. Démarrez la console MMC
  2. Ajoutez le complément logiciel enfichable Certificats. Sélectionnez le magasin Ordinateur de l’ordinateur local.
  3. Ouvrez le magasin Personnel…Certificats et recherchez le certificat que vous avez créé pour signer les jetons SAML. Si vous avez suivi mes indications ci-dessus pour le créer, le certificat se trouve là par défaut. Si vous l’avez créé d’une autre manière, vous devrez peut-être l’ajouter à ce magasin.
  4. Cliquez avec le bouton droit sur le certificat et choisissez l’option Gérer les clés privées.
  5. Dans la liste des utilisateurs ayant des droits aux clés, ajoutez Service réseau et accordez-lui les droits de lecture.

Notez que si vous n’effectuez pas cette opération correctement, lorsque vous essaierez d’exécuter l’application, vous risquez d’obtenir une erreur signalant que le jeu de clés n’existe pas. Cela signifie que le processus IIS n’avait pas les droits suffisants pour la clé privée et qu’il n’a donc pas pu l’utiliser pour signer le jeton SAML.

Installer l’application et les assemblys nécessaires

Installer l’application signifie en réalité créer une application ASP.NET dans IIS, copier les bits, et s’assurer que la dernière version de WIF est installée. Une fois que vous l’avez configurée et faite fonctionner sur un serveur, vous souhaiterez ajouter un ou plusieurs serveurs supplémentaires pour rendre la solution insensible aux défaillances. Mais, je vais me contenter d’explorer la configuration nécessaire sur un serveur unique.

Je n’expliquerai pas comment créer une application ASP.NET dans IIS. Vous pouvez le faire dans Visual Studio, dans le Gestionnaire des services Internet, etc.

Remarque : Si vous utilisez le code que je fournis ici, ouvrez simplement le projet dans Visual Studio, il signalera un hôte ou un site inexistant. C’est parce qu’il utilise le nom de mon serveur. La façon la plus simple de corriger cela est d’éditer manuellement le fichier WindowsLiveOauthSts.sln et de remplacer les valeurs https dans celui-ci par celles existant dans votre environnement.

Une fois l’application vraiment créée, vous devez effectuer les opérations suivantes :

  1. Ajoutez PassiveSTS.aspx comme document par défaut dans le Gestionnaire des services Internet pour le site web STS.
  2. Modifiez les paramètres d’authentification de l’application dans IIS de façon à désactiver tous les types d’authentification excepté l’authentification anonyme.
  3. Le STS doit s’exécuter via SSL, vous devez donc acquérir un certificat approprié et veiller à mettre à jour les liaisons sur le serveur virtuel IIS où l’application STS est utilisée.
  4. Assurez-vous de placer l’empreinte numérique du certificat de signature des jetons dans l’attribut thumbprint de l’élément add dans la section trustedIssuers du web.config de votre partie de confiance (si vous n’utilisez PAS SharePoint pour tester). Si vous utilisez l’assistant Ajouter une référence STS dans Visual Studio, il effectuera ces opérations à votre place.

C’est là toute la configuration nécessaire dans IIS.

Mettre à jour et générer le projet STS personnalisé

Le fichier zip joint est un projet Visual Studio 2010 appelé WindowsLiveOauthSts. Une fois IIS configuré et le fichier WindowsLiveOauthSts.sln mis à jour comme indiqué ci-dessus, vous devez pouvoir ouvrir le projet dans Visual Studio. En premier lieu, vous devez mettre à jour les constantes CLIENT_ID et CLIENT_SECRET dans la classe PassiveSTS.aspx.cs. Vous obtenez ces valeurs lorsque vous créez une nouvelle application Windows Live. Je ne vais pas détailler la procédure pas à pas (l’équipe Windows Live peut vous aider pour cela), mais je vais simplement vous diriger vers l’emplacement où créer votre application Windows Live : https://manage.dev.live.com/Applications/Index?wa=wsignin1.0. Lorsque vous créez votre application, assurez-vous de définir le Domaine de redirection comme l’emplacement où votre STS personnalisé est hébergé, c.-à-d. https://myserver.foo.com.

Maintenant que vous avez votre ID et votre secret, voici les mises à jour nécessaires dans l’application :

  1. Mettez à jour les constantes CLIENT_ID et CLIENT_SECRET dans la classe PassiveSTS.aspx.cs.
  2. Dans le fichier web.config, mettez à jour SigningCertificateName dans la section appSettings. Notez que vous n’avez pas à modifier le paramètre IssuerName, sauf si vous le souhaitez.
  3. Mettez à jour le certificat de signature de jetons du document FederationMetadata.xml dans le projet STS. Une fois que vous avez sélectionné le certificat à utiliser, vous pouvez vous servir de l’application test.exe incluse dans ce billet pour obtenir la chaîne du certificat. Vous devez la copier pour remplacer les deux valeurs de l’élément X509Certificate dans FederationMetadata.xml.

Un autre point mérite notre attention ici : dans le fichier CustomSecurityTokenService.cs, vous avez la possibilité de définir une variable appelée enableAppliesToValidation à true et de fournir ensuite la liste d’URL que ce STS personnalisé pourra utiliser. Dans mon cas, j’ai choisi de ne le restreindre d’aucune façon, donc cette variable est false. Si vous souhaitez verrouiller votre STS personnalisé, vous devez modifier cela maintenant. Une fois ces changements effectués, vous pouvez recompiler l’application qui sera alors prête à fonctionner.

À noter également ici : j’ai également inclus une application ASP.NET d’exemple qui m’a servi aux tests lors de ce projet. Elle se trouve dans un projet appelé LiveRP. Je ne vais pas m’y attarder ici, il vous suffit de savoir que vous pouvez vous en servir pour les tests. Souvenez-vous seulement de modifier l’empreinte numérique du certificat de signature des jetons STS comme décrit ci-dessus.

Configuration SharePoint

À ce stade, tout est configuré et devrait fonctionner avec le STS personnalisé. Il reste seulement à créer un nouvel émetteur SPTrustedIdentityToken dans SharePoint et configurer une application Web, nouvelle ou existante, à l’utiliser. Il vous faut connaître certaines notions pour configurer SPTrustedIdentityTokenIssuer, mais je vais vous donner la commande PowerShell que j’ai utilisée pour créer le mien et vous l’expliquerai ensuite :

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\livevbtoys.cer")

New-SPTrustedRootAuthority -Name "SPS Live Token Signing Certificate" -Certificate $cert

 

$map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/id" -IncomingClaimTypeDisplayName "WindowsLiveID" -SameAsIncoming

$map3 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/full_name" -IncomingClaimTypeDisplayName "FullName" -SameAsIncoming

$map4 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/first_name" -IncomingClaimTypeDisplayName "FirstName" -SameAsIncoming

$map5 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/last_name" -IncomingClaimTypeDisplayName "LastName" -SameAsIncoming

$map6 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/link" -IncomingClaimTypeDisplayName "Link" -SameAsIncoming

$map7 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/gender" -IncomingClaimTypeDisplayName "Gender" -SameAsIncoming

$map8 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/locale" -IncomingClaimTypeDisplayName "Locale" -SameAsIncoming

$map9 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/updated_time" -IncomingClaimTypeDisplayName "WindowsLiveLastUpdatedTime" -SameAsIncoming

$map10 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/account" -IncomingClaimTypeDisplayName "AccountName" -SameAsIncoming

$map11 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/accesstoken" -IncomingClaimTypeDisplayName "WindowsLiveAccessToken" -SameAsIncoming

$realm = "https://spslive.vbtoys.com/_trust/"

$ap = New-SPTrustedIdentityTokenIssuer -Name "SpsLive" -Description "Fournisseur d’identités oAuth Windows Live pour SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3,$map4,$map5,$map6,$map7,$map8,$map9,$map10,$map11 -SignInUrl "https://spr200.vbtoys.com/WindowsLiveOauthSts/PassiveSTS.aspx" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

Voici les éléments à noter :

  1. Comme je l’ai dit plus haut, j’ai créé un certificat appelé livevbtoys.cer pour signer mes jetons, que j’ai donc ajouté à ma liste SPTrustedRootAuthority et ensuite associé à mon émetteur de jetons.
  2. J’ai créé des mappages de revendications pour toutes les revendications que mon STS personnalisé retourne. Comme vous pouvez l’observer, c’est bien mieux que ce que vous pourriez obtenir en fédérant directement vers Windows Live. Un autre point à noter ici : j’inclus le jeton d’accès que Windows Live m’a retourné comme revendication. Bien que cela fonctionne avec Facebook, je ne l’ai pas testé donc je ne peux pas vous garantir si Windows Live vous laissera le réutiliser ou non. Cela fera peut-être l’objet d’un futur billet.
  3. La valeur $realm est extrêmement importante. Elle doit pointer vers le site racine de votre application Web et inclure le répertoire /_trust/. Si vous vous trompez, vous obtiendrez des erreurs 500 de SharePoint lors de la redirection après l’authentification.
  4. Le paramètre –SignInUrl lors de la création de l’émetteur de jetons est l’URL absolue de la page PassiveSTS.aspx pour mon STS personnalisé.

C’est à peu près tout – une fois configuré, vous utilisez toujours le sélecteur de personnes et les fournisseurs de revendications fournis, donc vous n’aurez aucune possibilité de recherche, évidemment. Vous accordez des droits aux personnes avec les adresses de messagerie qu’elles utilisent pour se connecter à Windows Live. Vous pourriez en réalité étendre cet exemple et utiliser aussi le fournisseur de revendications Azure dont j’ai parlé dans ce billet : https://blogs.msdn.com/b/sharepoint_fr/archive/2012/03/07/le-fournisseur-de-revendications-personnalis-233-es-azure-pour-projet-sharepoint-partie-1.aspx. Cela signifie que vous utiliserez ce STS afin de vous authentifier avec Windows Live et obtenir des revendications SAML réelles en retour, puis que vous utiliserez le projet du fournisseur de revendications Azure personnalisé pour ajouter ces utilisateurs authentifiés à votre magasin de répertoires Azure, et le sélecteur de personnes pour les choisir.

Les images montrent tout, voici donc l’écran obtenu lorsque vous accédez pour la première fois au site SharePoint afin de vous authentifier avec Windows Live :

À la première connexion, il vous sera demandé si vous souhaitez partager vos informations avec l’application STS personnalisée. Il n’y a aucune inquiétude à avoir ici, c’est la manifestation standard des autorisations OAuth. Voici à quoi cela ressemble ; notez que les données que je demande au STS sont affichées – vous pourriez aussi demander un jeu de données totalement différent. Il vous suffit de voir le Windows Live OAuth SDK pour comprendre ce que vous devez changer et comment le faire :

Après avoir accepté, vous êtes redirigé vers le site SharePoint. Dans cet exemple, j’utilise le composant WebPart de revendications SharePoint dont j’ai parlé dans ce billet : https://blogs.technet.com/b/speschka/archive/2010/02/13/figuring-out-what-claims-you-have-in-sharepoint-2010.aspx. Vous pouvez voir toutes les revendications que j’ai obtenues auprès de Windows Live via OAuth, dont je dispose maintenant comme revendications SAML grâce à mon STS personnalisé, et constater que je me suis connecté avec mon adresse de messagerie Windows Live que j’ai créée pour ce projet (à partir du contrôle de connexion, dans le coin supérieur gauche) :

 

Ce billet de blog a été traduit de l’anglais. Vous trouverez la version originale ici Finally A USEFUL Way to Federate With Windows Live and SharePoint 2010 Using OAuth and SAML