Wann für die Suchfunktion in SharePoint 2010 ein benutzerdefinierter Anspruchsanbieter installiert werden muss

Veröffentlichung des Originalartikels: 21.03.2011

Wir hatten vor Kurzem interessante Gespräche zum Thema benutzerdefinierte Anspruchsanbieter und Suchfunktion. Wie sich herausstellte, gibt es Fälle, bei denen Sie Ihren benutzerdefinierten Anspruchsanbieter für ein Suchfeld ("Feld" definiere ich weiter unten) installieren müssen, damit Einschränkung aus Sicherheitsgründen ordnungsgemäß auf Suchergebnisse angewendet werden. Wann dies zutrifft, hängt allerdings davon ab, ob Sie FAST Search 2010 oder SharePoint Search 2010 verwenden.

Zunächst möchte ich hier eine kurze Erläuterung einfließen lassen. Immer wenn ein Benutzer eine Abfrage sendet, werden die Ansprüche im Benutzertoken decodiert. Der Websitedaten-Webdienst, mit dessen Hilfe der Crawler Sicherheitsinformationen zum Inhalt abruft, gibt jedoch stets codierte Ansprüche zurück. Wie können wir das in Einklang bringen?

In FAST Search 2010 werden die Ansprüche stets decodiert, bevor sie von der FAST Search 2010-Indexerstellungsfunktion gespeichert werden. Dies erfolgt, weil auf den FAST-Abfrageservern nicht die SharePoint-Bits installiert sind, weshalb auf diesen die Ansprüche nicht codiert werden können. Wie bereits erwähnt, gehen die Benutzeransprüche codiert ein. Um also die codierten Ansprüche, die der Websitedaten-Webdienst zurückgibt, abgleichen zu können, müssten die Benutzeransprüche für einen Vergleich codiert sein. Da wir keinen benutzerdefinierten Anspruchsanbieter auf einem FAST-Abfrageserver installieren können, müssen wir die vom Websitedaten-Webdienst zurückgegebenen Ansprüche decodieren. Hierzu muss der verwendete benutzerdefinierte Anspruchsanbieter in der FAST-Inhaltssuchdienstanwendung installiert werden. Dies ermöglicht anschließend das Decodieren der Ansprüche, deren Speicherung und das Verwenden für einen Vergleich, wenn die decodierten Ansprüche eines Benutzers vorgelegt werden. Im Falle von FAST müssen benutzerdefinierte Anspruchsanbieter zum Zeitpunkt der Durchforstung verwendet werden.

Bei SharePoint Search 2010 liegt das umgekehrte Problem vor. SharePoint geht von einer Installation an einem beliebigen Speicherort aus und funktioniert deshalb unter der Voraussetzung, dass zum Zeitpunkt der Abfrage die Ansprüche des Benutzers codiert werden können, damit ein Vergleich mit den Zugriffssteuerungslisten erfolgen kann, die für den Inhalt gespeichert sind. Dieses Szenario funktioniert allerdings nicht mehr, wenn der benutzerdefinierte Anspruchsanbieter nicht auf Servern bereitgestellt ist, auf denen der Abfrageprozessor, d. h. der Suchabfrage- und Websiteeinstellungsdienst, ausgeführt wird. In den meisten Fällen installieren Sie Ihren benutzerdefinierten Anspruchsanbieter auf allen Servern in der Farm, also sowohl auf Front-End-Webservern als auch auf Anwendungsservern. Für den Abfrageprozessor muss dieser benutzerdefinierte Anspruchsanbieter installiert sein, damit die Ansprüche codiert werden können. Wenn alle Vorgänge in einer einzelnen Farm ablaufen und Sie den benutzerdefinierten Anspruchsanbieter auf allen Servern installieren, sollte alles in Ordnung sein. Eine Situation, die mir vor Kurzem geschildert wurde (und diesen Beitrag ausgelöst hat), war eine gesonderte Serverfarm für Dienste, in der die SharePoint Search-Dienste genutzt werden. In diesem Fall müssen Sie dafür sorgen, dass benutzerdefinierte Anspruchsanbieter auf allen Servern in der Farm für Dienste installiert werden, auf denen der Suchabfrage- und Websiteeinstellungsdienst ausgeführt wird. Wenn dies nicht erfolgt, werden die benutzerdefinierten Ansprüche der Benutzer nicht ausgewertet, sodass in der Regel keine Suchergebnisse zurückgegeben werden.

Dies war ein interessanter Fall, mit dem sich verschiedene Leute erfolgreich auseinander gesetzt haben. Hervorheben möchte ich meinen brillanten kleinen Bruder Luca, der uns half, das letzte Hindernis aus dem Weg zu räumen, sowie Sanjeev und Michael P. Dank an alle, die uns geholfen haben, dies besser zu verstehen.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter When Do You Need to Install a Custom Claims Provider for Search in SharePoint 2010