Partager via

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

  • Article

Résumé :  découvrez cinq conseils en rapport avec l’authentification basée sur les revendications dans SharePoint 2010, notamment la résolution des noms de revendications, la configuration de zones spécifiques, le déploiement de solution par défaut et la résolution des messages d’erreur.

Dernière modification : lundi 14 mars 2011

S’applique à : Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Dans cet article
Vue d’ensemble de la portée de cet article
Conseil 1 : configuration d’un fournisseur de revendications personnalisées à utiliser uniquement sur des zones sélectionnées dans SharePoint 2010
Conseil 2 : résolution des noms de revendications
Conseil 3 : connexion et les fameuses trois invites d’ouverture de session lors de l’authentification
Conseil 4 : déploiements de solutions par défaut pour les fournisseurs de revendications personnalisées
Conseil 5 : résolution d’une erreur TrustedMissingIdentityClaimSource avec l’authentification basée sur les revendications
Conclusion
Ressources supplémentaires

Auteur :  Steve Peschka, Microsoft Corporation

Sommaire

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

  • Conseil 1 : configuration d’un fournisseur de revendications personnalisées à utiliser uniquement sur des zones sélectionnées dans SharePoint 2010

  • Conseil 2 : résolution des noms de revendications

  • Conseil 3 : connexion et les fameuses trois invites d’ouverture de session lors de l’authentification

  • Conseil 4 : déploiements de solutions par défaut pour les fournisseurs de revendications personnalisées

  • Conseil 5 : résolution d’une erreur TrustedMissingIdentityClaimSource avec l’authentification basée sur les revendications

  • Conclusion

  • Ressources supplémentaires

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.

Conseil 1 : configuration d’un fournisseur de revendications personnalisées à utiliser uniquement sur des zones sélectionnées dans SharePoint 2010

La question suivante en rapport avec les scénarios d’utilisation de fournisseurs de revendications m’a déjà été posée à plusieurs reprises : comment configurer un fournisseur de revendications personnalisées à utiliser uniquement pour une application Web spécifique ou pour quelques applications Web, plutôt que pour toutes les applications Web ? J’espérais initialement que l’on pourrait répondre aux exigences de ce scénario de manière simple, en affectant l’application Web spécifique (plutôt que la batterie) comme portée de la fonctionnalité du fournisseur de revendications. Malheureusement, cela n’a pas fonctionné.

Une fonctionnalité d’un fournisseur de revendications personnalisées doit toujours avoir comme portée la batterie entière. Si vous configurez autrement la portée de votre fonctionnalité, vous obtiendrez une erreur : « La méthode ou l’opération n’est pas implémentée ».

Si la portée de la fonctionnalité est la batterie entière, comment configurer le fournisseur de revendications de sorte qu’il soit utilisé uniquement sur certaines applications Web ou zones ? La réponse est compliquée. Pour commencer, il faut bien comprendre deux propriétés très importantes d’un fournisseur de revendications dans la classe SPClaimProviderDefinition : les propriétés IsEnabled et IsUsedByDefault. Par défaut, lorsque vous installez une nouvelle fonctionnalité de fournisseur de revendications, les propriétés IsEnabled et IsUsedByDefault du fournisseur de revendications ont la valeur true. Cela signifie que votre fournisseur de revendications est utilisé partout où les revendications SAML (Security Assertion Markup Language) sont activées sur une zone. Par conséquent, pour pouvoir configurer un fournisseur de revendications à utiliser uniquement sur certaines zones, nous devons d’abord modifier la propriété IsUsedByDefault et lui affecter la valeur false. Du moment que IsEnabled est true et que IsUsedByDefault est false, nous pouvons configurer l’utilisation du fournisseur de revendications zone par zone.

Bien entendu, la question suivante est : comment affecter la valeur false à IsUsedByDefault ? Plusieurs options s’offrent à nous. La première consiste à utiliser le récepteur de fonctionnalité que vous créez pour votre fournisseur de revendications personnalisées et à configurer la propriété à cet emplacement. Dans la substitution de l’événement FeatureActivated (que vous devriez déjà avoir codé, de toute façon), vous pouvez utiliser SPClaimProviderManager pour obtenir une référence à votre fournisseur et affecter la valeur false à la propriété IsUsedByDefault. Voici un exemple que j’ai utilisé dans l’un de mes fournisseurs de revendications.

SPClaimProviderManager cpm = SPClaimProviderManager.Local;
 
foreach (SPClaimProviderDefinition cp in cpm.ClaimProviders)
{
if (cp.ClaimProviderType == typeof(SqlClaimsProvider.SqlClaims))
       {
       cp.IsUsedByDefault = false;
              cpm.Update();
              break;
       }
}

Dans ce code, où typeof(SqlClaimsProvider.SqlClaims) est utilisé, substituez le nom de classe et d’assembly par votre fournisseur de revendications, par exemple typeof(MyProvider.MyClaims). Vous pouvez également envelopper le code dans une application personnalisée. C’est ce que j’ai fait et c’est également l’approche adoptée pour illustrer comment le reste fonctionne tout au long de cet article.

La Figure 1 est une capture d’écran de mon application Claims Provider Activation. Sur le côté gauche de l’application figure une liste de mes fournisseurs de revendications personnalisées enregistrés (dans cet exemple, il n’y en a qu’un). Les cases à cocher au-dessous des fournisseurs de revendications personnalisées enregistrés permettent de modifier les propriétés IsEnabled et IsUsedByDefault pour le fournisseur de revendications personnalisées enregistré sélectionné.

Notes

Pour télécharger et essayer l’application Claims Provider Activation, voir Configuration d’un fournisseur de revendications personnalisées à utiliser uniquement sur certaines zones dans SharePoint 2010(éventuellement en anglais).

Figure 1. Application Claims Provider Activation affichant les fournisseurs de revendications personnalisées enregistrés

Application d’activation du fournisseur de revendications

Pour définir les propriétés, sélectionnez d’abord votre fournisseur de revendications personnalisées, activez les cases à cocher appropriées afin de définir les propriétés IsEnabled et IsUsedByDefault, puis cliquez sur le bouton Update.

Une fois que vous avez configuré votre fournisseur de revendications comme IsEnabled et non IsUsedByDefault, vous pouvez configurer les emplacements où il est utilisé. Après cela, il est utilisé uniquement lorsque l’objet SPIisSettings pour une zone contient le nom du fournisseur de revendications mentionné dans la propriété ClaimsProviders. L’accès à ces informations est un peu plus difficile si vous tentez de le faire de manière générique, comme je l’ai fait dans mon application Claims Provider Activation. La première étape consiste à énumérer toutes les applications Web, à l’aide de la classe SPService.

//Get the content service.
SPWebService ws = SPWebService.ContentService;
 
//Get each web application.
foreach (SPWebApplication wa in ws.WebApplications)
{
//Enumerate each zone in each web application.
}

L’énumération de chaque zone d’une application Web est une opération moins courante. Voici un exemple de la façon d’énumérer chaque zone.

foreach (SPAlternateUrl aam in wa.AlternateUrls)
{
//Look at each zone to see whether it is using SAML claims.
}

Pour déterminer si une zone utilise des revendications SAML, je commence par obtenir l’objet SPIisSettings de la zone. Comme mentionné plus haut, pour ajouter ou supprimer mon fournisseur de revendications de la propriété ClaimsProviders, j’aurai besoin de cela de toute façon. L’extrait de code suivant montre comment j’obtiens l’objet SPIisSetting de la zone.

SPIisSettings curConfig = wa.GetIisSettingsWithFallback(aam.UrlZone);

Dans ma variable curConfig, je peux examiner la propriété ClaimsAuthenticationProviders. Si une zone est configurée de façon à utiliser des revendications, la propriété ClaimsAuthenticationProviders n’est pas nulle et le nombre est supérieur à zéro.

J’énumère tous les fournisseurs de revendications et, si je trouve celui dont l’objet SPIisSettings pour une zone contient le nom du fournisseur de revendications mentionné dans la propriété ClaimsProviders, j’ajoute la zone à ma liste de zones et je l’affiche comme activée. Sinon, je ne peux pas utiliser mon fournisseur de revendications personnalisées avec cette zone. Par conséquent, j’ajoute tout de même la zone à la liste de zones, mais je l’affiche comme désactivée.

Voilà la procédure de base qui me permet de générer la liste d’applications Web et de zone et de déterminer les zones qui peuvent utiliser un fournisseur de revendications personnalisées.

Avec cette liste de zones, pour toute zone spécifique, mon fournisseur de revendications est utilisé si le nom du fournisseur de revendications se trouve dans la propriété ClaimsProviders de l’objet SPIisSettings.

La propriété ClaimsProviders est en fait un IEnumerable de type string ; son utilisation est par conséquent un peu délicate car elle ne contient aucune méthode surchargée pour exécuter des opérations Add, Remove ou RemoveAt sur des éléments. Pour contourner ce problème, je prends la propriété et je la convertie en une List<string>, ce qui me permet d’ajouter ou de supprimer le nom de mon fournisseur de revendications, puis de réaffecter la List<string> à la propriété ClaimsProviders.

Voici un exemple du code.

List<string> providers = theZoneIisSettings.ClaimsProviders.ToList();
 
//NOTE: myClaimProvider is type SPClaimProviderDefinition.
if (EnableProvider)
providers.Add(myClaimProvider.ClaimProvider.Name);
else
       providers.Remove(myClaimProvider.ClaimProvider.Name);
 
//Plug the new values back into the ClaimsProviders Ienumerable.
theZoneIisSettings.ClaimsProviders = providers;
 
//You must get the web application that contains the zone, and then call its
//Update method to save your changes.
theWebApp.Update();

La Figure 2 montre ce à quoi ressemble la sélection d’application Web et de zone dans l’application Claims Provider Activation.

Figure 2. Application Claims Provider Activation montrant l’application Web et les zones pour un fournisseur de revendications personnalisées spécifique

Application d’activation du fournisseur de revendications et zones

Dans le cas présent, le menu indique Enable Basketball Teams car mon fournisseur Basketball Teams n’est pas activé pour cette zone. S’il l’était, le menu indiquerait Disable Basketball Teams. Remarquez que dans les zones au-dessus, l’application Web SharePoint – Anon Profile Test est désactivée. Ceci est dû au fait que ces zones ne sont pas configurées pour utiliser des revendications SAML.

Voilà le principe de fonctionnement global. Il est un peu compliqué, mais sa configuration offre néanmoins beaucoup de flexibilité.

Conseil 2 : résolution des noms de revendications

Je voudrais maintenant essayer de partager avec vous quelques informations concernant les problèmes de résolution de noms de revendications qui peuvent se présenter. Dans certains cas, la résolution de noms ne fonctionne pas du tout (par exemple, lorsque vous tapez un nom dans le contrôle d’entrée et que vous cliquez sur le bouton de résolution). Il se peut même que vous ayez attaché un débogueur, si vous avez développé un fournisseur de revendications personnalisées, et que votre fournisseur de revendications effectue les opérations souhaitées, mais que le nom que vous avez tapé soit tout de même souligné en rouge et que la recherche indique qu’aucune correspondance n’a été trouvée.

Lorsque ce problème se produit, vous constaterez généralement que les fournisseurs de revendications par défaut ne fonctionnent plus non plus. Par exemple, vous pouvez taper NT Authority/Tous les utilisateurs authentifiés et la résolution échoue.

La cause de ce problème est la suivante : un fournisseur de revendications, quelque part, lève une exception lorsque sa surcharge FillResolve est appelée. Ce qui est le plus troublant ici, comme vous l’aurez compris d’après l’introduction, est le fait qu’un fournisseur de revendications défectueux peut provoquer le non-fonctionnement de toute la résolution de noms dans votre batterie.

Si vous vous retrouvez dans ce scénario, où les fournisseurs de revendications par défaut ne résolvent plus les noms, commencez par rechercher les fournisseurs de revendications personnalisées. Il vous faudra sans doute les supprimer un par un avant d’identifier celui qui pose problème, si vous n’avez pas écrit tous ces fournisseurs de revendications personnalisées. Cette suppression entraîne bien entendu quelques problèmes : en effet, si vous les rajoutez dans un ordre différent, ils ne génèreront pas les mêmes revendications sous-jacentes que précédemment (car une partie de la revendication est basée sur l’ordre dans lequel le fournisseur de revendications a été ajouté).

Néanmoins, le principal est de savoir ce qu’il faut rechercher lorsque l’on fait face à ce problème, et comment le résoudre.

Notes

Les informations précédentes démontrent quoi qu’il en soit que les développeurs de fournisseurs de revendications personnalisées ne doivent pas lever d’exceptions dans les fournisseurs de revendications, sous peine de jouer le rôle de fournisseur « coupable » susceptible d’empêcher la résolution des noms dans une batterie.

Conseil 3 : connexion et les fameuses trois invites d’ouverture de session lors de l’authentification

Le problème des trois invites d’ouverture de session lors de l’authentification est malheureusement très courant. Je l’ai rencontré ce week-end sur mon serveur AD FS (Active Directory Federation Services) que, malheureusement, j’étais en train de recréer. Les causes les plus courantes de l’affichage de ces invites sont liées à la configuration incorrecte du paramètre de protocole Kerberos ou à l’utilisation d’un nom autre que celui du serveur pour une application Web (scénario de boucle de désactivation).

Ce problème était toutefois différent, car spécifique à un serveur AD FS, c’est pourquoi j’ai souhaité le capturer à des fins de référence ultérieure.

Les Services ADFS (Active Directory Federation Services) 2.0 sont très performants lorsqu’il s’agit de consigner les problèmes dans le journal d’événements. Lorsque l’on ouvre l’Observateur d’événements, on constate la présence d’un nœud distinct pour les services ADFS 2.0. Ce nœud des services ADFS 2.0 est à l’emplacement à consulter si l’on souhaite identifier la cause du problème. Dans ce cas particulier, j’y ai trouvé le coupable. Cela m’a pris un certain temps car de nombreux éléments peuvent provoquer l’affichage de ces fameuses trois invites d’ouverture de session.

Lors de la configuration de mon serveur AD FS, j’ai procédé comme suit :

  • j’ai configuré le serveur AD FS de façon à s’exécuter comme compte de domaine ;

  • j’ai utilisé un certificat que j’avais créé uniquement pour les services AD FS pour la signature de jeton.

Le problème était le suivant : le compte de service que j’utilisais pour les services AD FS ne disposait pas de droit d’accès à la clé privée de mon certificat de signature de jeton. Cela provoquait l’affichage des trois invites d’ouverture de session, ce qui est à la fois intéressant, étonnant et frustrant.

Pour accorder au compte de service des droits d’accès à la clé privée pour le certificat, procédez comme suit :

  1. Exécutez la console MMC (Microsoft Management Console).

  2. Ajoutez le composant logiciel enfichable MMC Certificat(éventuellement en anglais)(Certmgr.dll) pour l’Ordinateur local.

  3. Ouvrez le nœud Personnel.

  4. Cliquez avec le bouton droit sur le certificat de signature de jeton, puis sélectionnez Gérer la clé privée.

J’espère que ces informations permettront à certains d’entre vous de gagner du temps.

Conseil 4 : déploiements de solutions par défaut pour les fournisseurs de revendications personnalisées

L’un de mes meilleurs amis, Tom W. (auteur du livre blanc sur le protocole Kerberos dans SharePoint 2010(éventuellement en anglais)), a souligné un aspect intéressant concernant les limitations du déploiement de solution et l’impact sur les fournisseurs de revendications personnalisées. Il convient de se souvenir que lorsque l’on développe un fournisseur de revendications personnalisées, celui-ci peut être utilisé à différents endroits en plus des applications Web pour utilisateurs finaux. Par exemple, lorsque vous créez des stratégies d’applications Web dans l’Administration centrale, il est utilisé à cet emplacement. Lorsque vous configurez des droits utilisateur sur Mes sites, il est appelé à cet emplacement. Si vous utilisez le Service Banque d’informations sécurisé, il est également appelé.

Le problème se manifeste à mesure que l’on crée des batteries de plus grande taille. Ces services étant appelés dans l’infrastructure des fournisseurs de revendications personnalisées, l’assembly de chaque fournisseur de revendications personnalisées doit être placé dans le Global Assembly Cache sur chacun de ces serveurs. Toutefois, par défaut, l’infrastructure de déploiement de solution SharePoint déploie les solutions uniquement sur les serveurs Web frontaux.

Lorsque l’on observe le schéma de déploiement de solution, on constate que les seules options disponibles pour l’attribut DeploymentServerType sont la valeur ApplicationServer ou la valeur WebFrontEnd. En fait, toutes deux sont nécessaires car dans les batteries à grande échelle il se peut que vous n’exécutiez pas le service d’application Web sur vos serveurs d’applications. Dans ce cas, vos fournisseurs de revendications personnalisées ne se trouvent pas dans le Global Assembly Cache sur ces serveurs. Si vous essayez d’utiliser l’une des fonctionnalités qui appelle l’infrastructure de fournisseurs de revendications personnalisées, des erreurs sont générées car l’assembly est manquant.

Malheureusement, les seules solutions de contournement sont les suivantes :

  1. Exécuter le service d’application Web sur tous les serveurs de la batterie.

  2. Écrire un travail de déploiement, récepteur d’événements ou travail de minuteur personnalisé, ou quelque chose de similaire, afin de déployer l’assembly sur tous les serveurs d’applications.

  3. Déployer l’assembly manuellement.

Aucune de ces options ne me semble particulièrement plaisante. Si je devais en choisir une, j’opterais pour la première (exécuter le service d’application Web sur tous les serveurs de la batterie) et je laisserais ces serveurs en dehors du pool d’équilibrage de la charge des utilisateurs finaux.

Voilà. Je souhaitais pour le moment uniquement attirer votre attention sur ce problème, de sorte que vous puissiez planifier en conséquence. Merci à Tom d’avoir signalé l’existence de ce problème.

Conseil 5 : résolution d’une erreur TrustedMissingIdentityClaimSource avec l’authentification basée sur les revendications

Ayant déjà rencontré l’erreur TrustedMissingIdentityClaimSource à plusieurs reprises, je souhaitais partager avec vous mon opinion quant au coupable le plus probable. Le scénario est le suivant : vous configurez l’authentification basée sur les revendications dans SharePoint 2010. Vous êtes à peu près sûr d’avoir tout configuré correctement.

Toutefois, lorsque vous essayez de naviguer vers le site, vous pouvez recevoir la page d’erreur standard Microsoft ASP.NET qui signale une erreur TrustedMissingIdentityClaimSource (en supposant que les erreurs personnalisées soient désactivées). J’ai constaté que cette erreur apparaissait le plus souvent lorsque des adresses de messagerie sont configurées de façon à être la revendication d’identité et que la personne que vous tentez de connecter ne possède pas d’adresse de messagerie dans Active Directory (ou autre répertoire utilisé). Cela peut laisser perplexe car on est redirigé vers les services AD FS (pour les besoins de cette discussion, il pourrait également s’agir de tout service d’émission de jeton de sécurité de fournisseur d’identité). On constate que l’on a été authentifié dans les services AD FS, mais ensuite on reçoit l’erreur TrustedMissingIdentityClaimSource dans Microsoft SharePoint Server.

Cette erreur sert de rappel quant à la différence entre qui je suis (l’identité avec laquelle je me connecte) et les éléments qui me concernent (par exemple des attributs tels que mon adresse de messagerie et d’autres revendications qui peuvent être utilisées pour la mise en service d’autorisations dans SharePoint 2010).

Si vous recevez cette erreur, je vous conseille de vérifier en premier lieu si le compte d’utilisateur que vous utilisez pour vous connecter a une valeur de revendication d’identité attendue par le fournisseur d’identité. Souvenez-vous également que s’il n’y a aucune valeur dans cet attribut, la revendication ne sera vraisemblablement même pas envoyée à SharePoint Server (autrement dit, elle ne sera pas envoyée en tant que valeur chaîne vide).

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 :