Conseils relatifs aux revendications 1 : authentification basée sur les revendications dans SharePoint 2010

Article
07/02/2015

Résumé : découvrez cinq conseils liés à l’authentification basée sur les revendications dans SharePoint 2010.

Dernière modification : vendredi 12 août 2011

Dans cet article
Vue d’ensemble de la portée de cet article
Conseil 1 : création de plusieurs applications Web à authentification par revendications dans une même batterie SharePoint 2010
Conseil 2 : migration d’une application Web de l’authentification Windows classique vers l’authentification Windows par revendications dans Shareoint 2010
Conseil 3 : utilisation d’audiences avec des sites à authentification par revendications dans SharePoint 2010
Conseil 4 : création d’une revendication d’identité et d’une revendication de rôle pour une application SharePoint 2010 à authentification par revendications
Conseil 5 : détermination des revendications dont vous disposez dans SharePoint 2010
Conclusion
Ressources supplémentaires

Auteur : Steve Peschka, Microsoft Corporation

Contenu

Vue d’ensemble de la portée de cet article
Conseil 1 : création de plusieurs applications Web à authentification par revendications dans une même batterie SharePoint 2010
Conseil 2 : migration d’une application Web de l’authentification Windows classique vers l’authentification Windows par revendications dans Shareoint 2010
Conseil 3 : utilisation d’audiences avec des sites à authentification par revendications dans SharePoint 2010
Conseil 4 : création d’une revendication d’identité et d’une revendication de rôle pour une application SharePoint 2010 à authentification par revendications
Conseil 5 : détermination des revendications dont vous disposez dans SharePoint 2010
Conclusion
Ressources supplémentaires

Téléchargez l’exemple de code qui accompagne cet article :SharePointClaims_MSDNExample.zip(éventuellement en anglais)

Vue d’ensemble de la portée de cet article

Cet article fournit des conseils et des réponses aux questions les plus fréquentes concernant l’authentification basée sur les revendications dans Microsoft SharePoint 2010. Il contient également des conseils et des instructions pour vous aider à résoudre les problèmes liés à l’utilisation et à la configuration des revendications et pointe vers d’autres ressources où vous trouverez davantage d’informations.

Notes

L’exemple de code qui accompagne cet article, SharePointClaims_MSDNExample.zip(éventuellement en anglais), concerne le Conseil 5 : détermination des revendications dont vous disposez dans SharePoint 2010.

Conseil 1 : création de plusieurs applications Web à authentification par revendications dans une même batterie SharePoint 2010

Le principal aspect qui prête à confusion en ce qui concerne la configuration de plusieurs applications Web qui utilisent l’authentification par revendications dans SharePoint 2010 concerne l’objet SPTrustedIdentityTokenIssuer. Comme mentionné dans mon entrée de blog Considérations relatives à la planification de l’authentification basée sur les revendications dans SharePoint 2010(éventuellement en anglais), il est possible d’associer un certificat de signature de jeton uniquement à partir d’un service d’émission de jeton de sécurité ayant un seul objet SPTrustedIdentityTokenIssuer. Lorsque vous créez votre objet SPTrustedIdentityTokenIssuer, vous indiquez à l’objet SPTrustedIdentityTokenIssuer :

le certificat de signature de jeton que vous utilisez ;
le domaine que vous utilisez.

Le domaine est important car il est inclus dans la chaîne de requête renvoyée à votre service d’émission de jeton de sécurité. Celui-ci utilise ce domaine pour identifier quelle partie de confiance vous êtes, et ainsi déterminer les règles de revendications à traiter, l’URL à utiliser pour rechercher la stratégie d’approbation pour l’application Web, et ainsi de suite. Bien qu’il soit possible d’ajouter plusieurs certificats de signature de jeton à quelque chose comme les Services ADFS (Active Directory Federation Services) 2.0, il n’existe aucun moyen d’indiquer qu’un certificat de signature de jeton donné doit être utilisé avec une partie de confiance donnée. Il convient donc de trouver un moyen d’opérer avec un seul certificat.

L’objet SPTrustedIdentityProvider possède une propriété ProviderRealms qui prend plusieurs domaines. Supposez par exemple que vous avez deux applications Web :https://collab et https://mysites. Vous utilisez Windows PowerShell pour créer un SPTrustedIdentityTokenIssuer qui ressemble un peu à l’extrait d’applet de commande suivant.

$realm = "urn:sharepoint:collab"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://URLToYourAdfsServer/adfs/ls" -IdentifierClaim https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

L’objet SPTrustedIdentityTokenIssuer est maintenant créé et son domaine par défaut est urn:sharepoint:collab. Nous créons une partie de confiance dans ADFS 2.0 et nous lui indiquons que les identifiants sont urn:sharepoint:collab et https://collab/_trust/. Maintenant, pour prendre en charge notre seconde application Web, nous devons ajouter un autre domaine à notre objet SPTrustedIdentityTokenIssuer. En voici le code Windows PowerShell.

$uri = new-object System.Uri("https://mysites")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:mysites")
$ap.Update()

L’élément essentiel est ici l’URI. Il s’agit de l’URL de l’application Web qui utilisera ce domaine. Durant l’authentification, SharePoint recherche le domaine associé à l’URI de cette application Web ; il s’agira de l’URI utilisé par SharePoint. Dans le cas présent, nous souhaitons que le domaine urn:sharepoint:mysites soit utilisé avec l’application Web à https://mysites ; nous avons donc spécifié cet URI lors de l’ajout du domaine. Nous pouvons maintenant revenir à ADFS 2.0 et définir une seconde partie de confiance avec un identifiant urn:sharepoint:mysites et https://mysites/_trust/, et tout devrait fonctionner correctement.

Conseil 2 : migration d’une application Web de l’authentification Windows classique vers l’authentification Windows par revendications dans Shareoint 2010

Que puis-je faire si j’ai une application Web qui utilise l’authentification Windows classique et que je souhaite la modifier de façon à utiliser l’authentification Windows par revendications ? Il se peut que vous ayez commencé avec l’authentification Windows classique et que vous vouliez maintenant passé à l’authentification par revendications, ou peut-être avez-vous mis à niveau un site SharePoint 2007. J’ai effectué cette procédure lors d’un test à petite échelle et souhaitais partager avec vous mes observations.

Attention
Une fois que vous avez basculé vers l’authentification par revendications, il est impossible de revenir à l’authentification Windows classique. Assurez-vous de disposer de bonnes sauvegardes avant de commencer ; j’ai sauvegardé ma base de données de contenu dans Microsoft SQL Server et mon application Web dans l’Administration centrale. Je vous recommande vivement d’appliquer d’abord cette procédure dans un laboratoire avant de passer en mode de production.

Une fois que vous avez basculé vers l’authentification par revendications, il est impossible de revenir à l’authentification Windows classique. Assurez-vous de disposer de bonnes sauvegardes avant de commencer ; j’ai sauvegardé ma base de données de contenu dans Microsoft SQL Server et mon application Web dans l’Administration centrale. Je vous recommande vivement d’appliquer d’abord cette procédure dans un laboratoire avant de passer en mode de production.

Ceci étant dit, la procédure en elle-même est relativement simple. Quelques lignes de code Windows PowerShell et quelques minutes devraient suffire. Voici les commandes Windows PowerShell.

$WebAppName = "http://yourWebAppUrl"
$account = "yourDomain\yourUser"
$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
#This causes a prompt about migration. Click Yes and continue.

#The following step sets the user as an administrator for the site. 
$wa = get-SPWebApplication $WebAppName
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()

#After the user is added as an administrator, we set the policy so that the user can have the correct access.
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

#The final step is to trigger the user-migration process.
$wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)

Après l’implémentation des commandes ci-dessus, il se peut encore que vous rencontriez certains problèmes :

Les utilisateurs ne parviennent pas à se connecter. Il se peut que des utilisateurs ne puissent pas se connecter au site. Après avoir entré vos informations d’identification, vous pouvez être informé du fait que vous êtes domaine\utilisateur, mais que vous ne disposez pas de droits d’accès. Si ce message s’affiche, il est probable que vous avez configuré les propriétés portalsuperuseraccount et portalsuperreaderaccount de l’application Web avant la migration. Vous devez les mettre à jour de façon à utiliser le nouveau nom de compte basé sur les revendications. Vous pouvez obtenir ce nom en examinant la stratégie d’application Web de l’application Web après la migration ; copiez le nom de compte depuis cet emplacement.
Des alertes existantes peuvent ne pas se déclencher. À l’heure actuelle, si des alertes existantes ne se déclenchent pas, la seule solution de contournement dont j’ai connaissance consiste à supprimer et à recréer les alertes.
L’analyse de recherche ne fonctionne pas. Vérifiez bien les stratégies d’applications Web et assurez-vous que le compte d’analyse de recherche possède le nouveau nom de compte converti. Si ce n’est pas le cas, vous devez créer manuellement une nouvelle stratégie pour le compte d’analyse.

Par ailleurs, l’applet de commande MigrateUsers s’exécutant dans un travail du minuteur, vous devrez peut-être patienter jusqu’à son achèvement. Personnellement, une fois terminé j’ai vérifié les éléments suivants :

Les utilisateurs peuvent se connecter Les utilisateurs qui sont ajoutés individuellement et ceux qui font partie d’un groupe Active Directory ayant été ajouté à un groupe SharePoint peuvent se connecter.
L’affichage Mes tâches d’une liste de tâches fonctionne. Les éléments qui m’ont été assignés en tant qu’utilisateur avec l’authentification classique Windows apparaissent toujours dans Mes tâches (autrement dit, le système comprend que « Steve revendications Windows » était auparavant « Steve classique Windows »).
Mes workflows d'approbation en cours de traitement sont toujours opérationnels. Je parviens encore à effectuer les flux de travail d’approbation.
Mes flux de travail SharePoint Designer personnalisés qui étaient en cours fonctionnent encore. Je parviens toujours à effectuer mes flux de travail personnalisés.
Je peux créer des flux de travail SharePoint Designer. Je parviens à créer des instances de flux de travail par défaut et des flux de travail SharePoint Designer personnalisés.
Je peux analyser l’application Web. Je parviens à effectuer une analyse de l’application Web sans problème.
Je peux interroger le contenu. Je parviens à interroger le contenu grâce à une analyse de l’application Web.

J’ai constaté une seule anomalie à ce jour : lorsque je crée une alerte dans le site, le système indique qu’elle a été créée avec succès (je reçois même un message électronique me le confirmant), mais lorsque j’accède à la gestion de mes alertes, l’alerte créée ne figure pas dans la liste. De plus, les modifications ne génèrent pas de message électronique d’alerte. Si je détecte d’autres anomalies, j’essaierai de les mentionner dans les mises à jour de mon blog(éventuellement en anglais).

Conseil 3 : utilisation d’audiences avec des sites à authentification par revendications dans SharePoint 2010

Il existe peut-être un aspect de l’utilisation des revendications SAML (Security Assertion Markup Language) auquel vous n’avez pas réfléchi : l’impact de la fonctionnalité des audiences dans SharePoint 2010. Par défaut, nous importons des utilisateurs uniquement à partir d’annuaires tels qu’Active Directory et quelques sources LDAP (Lightweight Directory Access Protocol) .

Le problème est que le nom de compte de la plupart des utilisateurs de revendications SAML ressemble à i:05:t|adfs with roles|fred@contoso.com. Alors peut-on utiliser des audiences avec ces utilisateurs de revendications ? La réponse est oui, heureusement, mais cela implique une dose de travail supplémentaire.

Avant tout, vous devez créer des profils pour ces personnes. Vous pouvez les créer manuellement ou en rédigeant du code. L’important est de créer ces profils et d’utiliser la chaîne similaire à i:05:t|adfs with roles|fred@contoso.com comme nom de compte, puis de remplir les autres champs avec les données que vous souhaitez utiliser dans vos audiences.

Ensuite, créez de nouvelles audiences. Vous ne pourrez pas utiliser d’audience basée sur les utilisateurs, telle que membre d’un groupe (en tous cas pas sans écrire de code, ce qui est hors de portée de cet article) Au lieu de cela, vous devez utiliser l’audience basée sur les propriétés. Dans mon scénario, j’ai utilisé le champ Bureau du profil comme base pour mon audience. J’ai créé deux profils pour deux utilisateurs de revendications différents et affecté à l’un d’eux la valeur Contoso pour Office et à l’autre la valeur Wingtip Toys pour Office. Ainsi, dans ma nouvelle audience, j’ai créé une règle où Office = Contoso et je l’ai nommée Contoso Employees. Après avoir compilé mon audience, j’ai pu observé que parmi ses membres figurait mon utilisateur de revendications.

Pour effectuer une validation plus approfondie, j’ai ensuite accédé à mon site de revendications et ciblé un composant WebPart sur une audience. La seule chose un peu imprévue que j’ai constatée est que le Sélecteur de personnes n’a pas été rempli correctement avec une liste de toutes les audiences. Toutefois, lorsque j’ai recherché Contoso Employees, le système a bien trouvé l’audience que j’avais créée. J’ai sélectionné cette audience comme ciblage du composant WebPart et enregistré les modifications. Pour finir, j’ai navigué jusqu’au site sous l’identité de mes deux utilisateurs de revendications différents. L’utilisateur qui faisait partie de l’audience Contoso Employees a vu le composant, contrairement à l’autre.

Conseil 4 : création d’une revendication d’identité et d’une revendication de rôle pour une application SharePoint 2010 à authentification par revendications

Pour différentes raisons, faire fonctionner correctement une application Web à authentification basée sur les revendications avec à la fois une revendication d’identité et une revendication de rôle a posé quelques problèmes. Par conséquent, je vais ici partager avec vous uniquement les étapes de création des revendications et de l’objet SPTrustedIdentityTokenIssuer.

Créez la revendication d’identité, comme indiqué dans le code suivant.

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

Créez la revendication de rôle, comme indiqué dans le code suivant.

$map2 = New-SPClaimTypeMapping -IncomingClaimType " https://schemas.microsoft.com/ws/2008/06/identity/claims/role " -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

Incluez les deux revendications lors de la création de votre objet SPTrustedIdentityTokenIssuer, comme indiqué dans le code suivant.

$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" 
-Realm "yourRealmName" -ImportTrustCertificate $yourCert -ClaimsMappings $map,$map2 
-SignInUrl "https://URLToYourAdfsServer/adfs/ls" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

L’essentiel ici est de penser à bien inclure les deux revendications lors de la création de votre émetteur de jeton, car vous ne pouvez pas les ajouter ultérieurement. Il s’agit de l’une des limitations de SPTrustedIdentityTokenIssuers.

Conseil 5 : détermination des revendications dont vous disposez dans SharePoint 2010

L’un des problèmes intéressants sur lesquels j’ai travaillé concernait certaines erreurs d’autorisations étranges obtenues sur un site d’authentification par revendications. La difficulté de résolution de ce problème réside partiellement dans le fait que nous n’énumérons pas ici les revendications que SharePoint pense que nous avons pour ensuite les déposer n’importe où.

Lorsque j’accédais à un site et obtenait une erreur de refus d’accès ou que je n’avais pas accès à tout le contenu prévu, je n’avais aucun moyen efficace de déterminer la cause de cette erreur. Pour aider à déboguer ces types de scénarios, j’ai écrit du code relativement simple qui m’indique les revendications que SharePoint possède pour moi, autrement dit la demande utilisateur actuelle. Je l’ai implémenté de deux manières.

Une partie de l’assembly est implémentée en tant que HttpModule. Elle énumère les revendications, puis les envoie au journal du Service de journalisation unifiée. Il est très facile de trouver ces entrées en filtrant ce journal sur la catégorie Énumération des revendications SharePoint. HttpModule est utile dans les cas où vous ne parvenez même pas à vous connecter au site.
La seconde partie de l’assembly est implémentée en tant que composant WebPart. Elle émet simplement les revendications que vous avez et la valeur de chaque revendication. Ceci est utile dans les scénarios dans lesquels vous pouvez vous connecter au site mais vous tentez de déterminer pourquoi vous n’avez pas accès à tout le contenu qui devrait normalement vous être accessible.

L’exemple de code de cet article, SharePointClaims_MSDNExample.zip(éventuellement en anglais), contient el code source et la version Debug de cet assembly ; consultez le fichier Instructions.txt pour obtenir les instructions.

J’ai découvert une autre chose importante au sujet des revendications dans SharePoint : après que vous vous êtes authentifié auprès de votre service d’émission de jeton de sécurité, votre jeton revient à SharePoint. SharePoint possède une liste de toutes les revendications qu’il s’attend à voir ; il recherche toutes celles-ci et crée avec elles un objet SPClaim. Si votre service d’émission de jeton de sécurité renvoie d’autres revendications en plus de celles qu’attend SharePoint, ce dernier ignore ces revendications supplémentaires et elles ne sont pas ajoutées à l’objet SPClaim. Ceci est intéressant à noter lors de la résolution des problèmes d’authentification par revendications.

Conclusion

Cet article fournit des réponses aux questions les plus fréquentes concernant l’authentification basée sur les revendications dans SharePoint 2010. Il contient également cinq conseils et des instructions pour vous aider à résoudre les problèmes liés à l’utilisation et à la configuration des revendications et pointe vers d’autres ressources où vous trouverez davantage d’informations.

Ressources supplémentaires

Pour plus d’informations, voir les ressources suivantes :