Share via


Quando precisamos instalar um provedor de declarações personalizado para pesquisa no SharePoint 2010

Artigo original publicado na quarta-feira, 21 de março de 2012

Temos tido algumas boas (entenda “interessante”) discussões ultimamente sobre os provedores de declarações personalizados e a pesquisa. Como resultado, houveram momentos quando você precisa instalar seu provedor de declaração personalizado em uma caixa de pesquisa (“caixa” sendo algo definido abaixo) para fazer o trabalho de filtragem de segurança funcionar corretamente em seus resultados de pesquisa. Quando isso se aplica é diferente dependendo do uso do FAST Search 2010 ou SharePoint Search 2010.

Primeiro uma breve explicação é útil aqui. Cada vez que um usuário realiza uma consulta, as declarações no token do usuário são decodificadas. No entanto, o Serviço Web do SiteData, que é o que o rastreador usa para recuperar a informação de segurança sobre o conteúdo, sempre retorna declarações codificadas. Portanto, como nós reconciliamos isso?

No FAST Search 2010, as declarações são sempre decodificadas antes de serem armazenadas pelo indexador do FAST Search 2010. Fazemos isso porque os servidores do FAST Query não possuem bits do SharePoint instalados, portanto eles não podem codificar as declarações. Lembre-se que as declarações do usuário são transmitidas decodificadas, portanto para que possam corresponder as declarações codificadas que o Serviço Web do SiteData devolve, as declarações do usuário precisam ser codificadas para realizar uma comparação. Como não podemos instalar um provedor de declaração personalizado em um servidor do FAST Query, temos que decodificar as declarações obtidas do Serviço Web do SiteData e para fazer isso qualquer provedor de declaração personalizado que você estiver usando deve ser instalado no SSA de Conteúdo do FAST. Fazer isso permite decodificar as declarações, armazenar as declarações decodificadas e, quando as declarações decodificadas para um usuário são apresentadas, podemos fazer uma comparação. No caso do FAST, estamos preocupados com o uso de qualquer provedor de declaração personalizado no tempo de rastreamento.

Para o SharePoint Search 2010, é praticamente o problema oposto. O SharePoint espera que seja instalado em qualquer lugar, portanto, funciona na premissa de que o tempo de consulta, pode codificar as declarações do usuário para que uma comparação possa ser realizado no ACLs armazenado para o conteúdo. Você encontrará este cenário onde não tiver implementando provedores de declarações personalizados para servidores executando o processador de consulta, também conhecido como Serviço de Configuração de Site e Consulta. Na maioria dos casos, você instala seu provedor de declarações personalizado em todos os servidores do seu farm - os WFEs assim como os servidores de aplicativos. O processador de consulta precisa deste provedor de declarações personalizado instalado para codificar as declarações. Portanto, se tudo está sendo executado em um único farm e você instalar o provedor de declarações personalizado em todos os servidores, está tudo bem. A situação que ocorreu recentemente (e que causou esta publicação) é um cenário onde você tem um farm de serviços separado e está consumindo os serviços do SharePoint Search deste farm. Neste caso, você precisa garantir que qualquer provedor de declaração personalizado seja instalado em cada servidor no farm de serviços que está executando o Serviço de Configuração de Site e Consulta. Se você não fizer isso, irá descobrir que as declarações personalizadas do usuário não podem ser avaliadas e, como resultado, eles geralmente não verão qualquer resultado retornado.

Este foi um cenário interessante e realizamos ótimas soluções de problemas por um conjunto de pessoas...especialmente falando do meu brilhante amigo Luca por nos ajudar com o obstáculo final, assim como Sanjeev e Michael P. Obrigado por nos ajudar a compreender isso melhor.

Esta é uma publicação localizada. Encontre o artigo original em When Do You Need to Install a Custom Claims Provider for Search in SharePoint 2010