Quand faut-il installer un fournisseur de revendications personnalisé pour la recherche dans SharePoint 2010 ?

Article d’origine publié le mercredi 21 mars 2012

Nous avons eu de bonnes discussions (c.-à-d. intéressantes) dernièrement sur la recherche et les fournisseurs de revendications personnalisés. Comme il s’avère, il y a des cas où vous devez installer votre fournisseur de revendications personnalisé sur une zone de recherche (je vais définir ce que j’entends par zone plus bas) afin que le filtrage de sécurité fonctionne correctement dans les résultats de votre recherche. Lorsque cela s’applique, c’est pourtant différent selon que vous utilisez FAST Search 2010 ou SharePoint Search 2010.

Tout d’abord, une petite explication est probablement utile ici. Chaque fois qu’un utilisateur effectue une requête, les revendications dans le jeton utilisateur sont décodées. Cependant le Service Web SiteData, que le robot utilise pour récupérer des informations de sécurité sur le contenu, retourne toujours les revendications codées. Alors, comment concilier cela ?

Dans FAST Search 2010, les revendications sont toujours décodées avant d’être stockées par l’indexeur de FAST Search 2010. Nous faisons cela parce que les serveurs de requêtes FAST n’ont pas les bits SharePoint installés, donc ils ne peuvent pas coder les revendications. N’oubliez pas que les revendications utilisateur arrivent décodées, alors pour correspondre aux revendications codées que le service Web SiteData retourne, les revendications utilisateur doivent être codées pour permettre la comparaison. Puisque nous ne pouvons pas installer un fournisseur de revendications personnalisé sur un serveur de requêtes FAST, nous devons décoder les revendications que nous recevons du service Web SiteData, et pour ce faire, tout fournisseur de revendications personnalisé que vous utilisez doit être installé dans le SSA de contenu FAST. Cela nous permet de décoder les revendications, de stocker les revendications décodées, et ensuite lorsque les revendications décodées d’un utilisateur sont présentées, de pouvoir faire une comparaison. Donc dans le cas de FAST, nous traitons l’utilisation de tout fournisseur de revendications personnalisé au moment de l’analyse.

Pour SharePoint Search 2010, le problème est en quelque sorte inverse. SharePoint prévoit qu’il sera installé partout, donc il fonctionne sur le principe qu’au moment de la requête, il peut encoder les revendications de l’utilisateur afin qu’une comparaison aux ACL stockés pour le contenu soit possible. Vous trouverez ces décompositions dans le cas où vous n’avez pas déployé le fournisseur de revendications personnalisé sur les serveurs qui exécutent le processeur de requêtes, aussi connu sous le nom de Service de paramètres de site et de requête. Dans la plupart des cas, vous installez votre fournisseur de revendications personnalisé sur tous les serveurs de votre batterie - WFE ainsi que les serveurs d’application. Le processeur de requêtes a besoin de lui pour coder les revendications. Donc si tout s’exécute dans une seule batterie et que vous installez le fournisseur de revendications personnalisé sur tous les serveurs, cela devrait fonctionner. La situation qui est apparue récemment (et qui a incité ce billet) est un scénario où il y a une batterie de services distincte et où vous consommer les services de recherche SharePoint de cette batterie. Dans ce cas, vous devez vous assurer que les fournisseurs de revendications personnalisés sont installés sur chaque serveur de la batterie de services qui exécute le Service de paramètres de site et de requête. Sinon, les revendications personnalisées de vos utilisateurs ne pourront pas être évaluées, et par conséquent ces derniers ne verront typiquement aucun résultat de recherche retourné.

C’était un scénario intéressant qui a demandé pas mal de résolution de problèmes par plusieurs personnes ici... en faisant tout spécialement appel à mon brillant petit frère Luca pour nous aider à franchir le dernier obstacle ici, ainsi qu’à Sanjeev et Michael P. Merci à tous de nous avoir aidé à mieux comprendre tout ça.

Ce billet de blog a été traduit de l’anglais. Vous trouverez la version originale ici When Do You Need to Install a Custom Claims Provider for Search in SharePoint 2010