Когда необходимо устанавливать настраиваемый поставщик утверждений для поиска в SharePoint 2010

Исходная статья опубликована в среду, 21 марта 2012 г.

За последнее время у нас состоялось несколько содержательных (в смысле "интересных") обсуждений настраиваемых поставщиков утверждений и поиска. Оказывается, бывают случаи, когда необходимо установить настраиваемый поставщик утверждений в поле поиска (определение слову "поле" я дам ниже), чтобы обеспечить правильную фильтрацию по ролям безопасности в результатах поиска. Однако применение отличается в зависимости от того, какой продукт используется: FAST Search 2010 или SharePoint Search 2010.

Пожалуй, для начала немного поясню. Всякий раз, когда пользователь делает запрос, утверждения в маркере пользователя декодируются. Но веб-служба SiteData, с помощью которой программа-обходчик (crawler) получает данные о безопасности контента, всегда возвращает кодированные утверждения. Как же нам их согласовать?

В FAST Search 2010 утверждения всегда декодируются, прежде чем сохраняются индексатором FAST Search 2010. Это делается потому, что на серверах запросов FAST нет установленных фрагментов SharePoint, так что они не могут декодировать утверждения. Как вы помните, утверждения пользователя передаются декодированными, поэтому для выполнения сравнения с кодированными утверждениями, возвращаемыми веб-службой SiteData, утверждения пользователя необходимо кодировать. Поскольку мы не можем установить настраиваемый поставщик утверждений на сервере запросов FAST, нам приходится декодировать утверждения, получаемые из веб-службы SiteData, и для этого необходимо установить используемый настраиваемый поставщик утверждений в FAST Content SSA. Это позволяет нам декодировать и сохранять декодированные утверждения, а затем, при наличии декодированных утверждений пользователя, мы можем выполнить сравнение. Итак, в случае FAST речь идет об использовании настраиваемых поставщиков утверждений во время обхода контента.

Для SharePoint Search 2010 проблема, можно сказать, противоположная. SharePoint предполагает, что он установлен везде, поэтому работает, исходя из того, что во время запроса можно кодировать утверждения, идущие от пользователя, чтобы выполнить сравнение со списками управления доступом (ACL), сохраненными для контента. Однако это не работает для сценария, при котором вы не развертываете настраиваемый поставщик утверждений на серверы, где работает процессор обработки запросов, называемый также службой запросов и параметров сайтов (Query and Site Settings Service). В большинстве случаев вы устанавливаете настраиваемый поставщик утверждений на все серверы в ферме — WFE и серверы приложений. Процессору обработки запросов необходим установленный настраиваемый поставщик утверждений, чтобы кодировать утверждения. Итак, если все компоненты работают в одной ферме, и вы устанавливаете настраиваемый поставщик утверждений для всех серверов, все должно быть в порядке. В недавней ситуации (которая и послужила поводом для этой записи) действует сценарий, при котором у вас имеется отдельная ферма служб, и вы используете службы поиска SharePoint из фермы. В этом случае нужно обязательно установить настраиваемые поставщики утверждений на каждом сервере в ферме служб, на котором работает служба запросов и параметров сайтов (Query and Site Settings Service). В противном случае окажется, что ваши настраиваемые утверждения пользователя нельзя оценить, в результате чего будут не видны возвращаемые результаты поиска.

Это был интересный сценарий, и над решением проблемы тут пришлось потрудиться разным людям... особенно хочу отметить моего замечательного младшего брата Луку, который помог нам преодолеть последнее препятствие, а также Санджива и Майкла П. Спасибо всем за то, что помогаете нам досконально разобраться в ситуации.

Это локализованная запись блога. Исходная статья доступна по ссылке: When Do You Need to Install a Custom Claims Provider for Search in SharePoint 2010