Quando installare un provider di attestazioni personalizzate per la ricerca in SharePoint 2010
Articolo originale pubblicato mercoledì 21 marzo 2012
Ultimamente abbiamo avuto delle belle (nel senso di "interessanti") discussioni sui provider di attestazioni personalizzate e sulla ricerca. Come è ovvio, vi sono casi in cui è necessario installare il provider di attestazioni personalizzate per una casella di ricerca (definirò più avanti cosa intendo per "casella" in questo caso) per far funzionare correttamente nei risultati di ricerca la limitazione per motivi di sicurezza. Nei casi di applicabilità, la situazione è tuttavia diversa a seconda che si stia utilizzando FAST Search 2010 oppure SharePoint Search 2010.
Forse a questo punto può essere utile una breve spiegazione. Ogni volta che un utente effettua una query, le attestazioni incluse nel suo token sono decodificate. Il servizio Web SiteData, che viene utilizzato dal crawler per recuperare le informazioni di sicurezza sul contenuto, però restituisce sempre attestazioni codificate Allora, come sono conciliabili le due cose?
In FAST Search 2010 le attestazioni vengono sempre decodificate prima di essere archiviate dall'indicizzatore. Questo avviene perché i server di query FAST non hanno il codice di SharePoint installato, quindi non possono codificare le attestazioni. Ricordare che le attestazioni utente arrivano decodificate. Pertanto, per poter trovare una corrispondenza con le attestazioni codificate restituite dal servizio Web SiteData, è necessario che le attestazioni utente siano codificate per consentire un confronto. Poiché non è possibile installare un provider di attestazioni personalizzate in un server di query FAST, è necessario decodificare le attestazioni inviate dal servizio Web SiteData e, a tale scopo, qualsiasi provider di attestazioni personalizzate in uso deve essere installato nell'applicazione del servizio di ricerca del contenuto FAST. Questo consente di decodificare le attestazioni, archiviarle decodificate e quindi eseguire un confronto quando vengono presentate le attestazioni decodificate di un utente. Nel caso di FAST, è perciò necessario preoccuparsi dell'utilizzo di qualsiasi provider di attestazioni personalizzate in fase di ricerca per indicizzazione.
Per SharePoint Search 2010, il problema è l'opposto. SharePoint prevede di essere installato ovunque, quindi funziona partendo dal presupposto di poter, in fase di query, codificare le attestazioni dell'utente in modo da consentire un confronto con gli ACL archiviati per il contenuto. Il comportamento cambia nel caso di uno scenario in cui il provider di attestazioni personalizzate non sia stato installato nei server che eseguono il sistema di elaborazione delle query, noto anche come Servizio query di ricerca e impostazioni sito. Nella maggior parte dei casi il provider di attestazioni personalizzate viene installato in tutti i server della farm, che si tratti di front-end Web o di server applicazioni. Il sistema di elaborazione delle query richiede che tale provider sia installato per poter codificare le attestazioni. Se pertanto tutti i componenti vengono eseguiti in una singola farm e il provider di attestazioni personalizzate viene installato in tutti i server, non ci dovrebbero essere problemi. La situazione emersa di recente (e che ha portato alla preparazione di questo post) riguarda uno scenario con una farm dei servizi separata in cui i servizi di ricerca SharePoint vengono utilizzati da tale farm. In questo caso è necessario verificare che qualsiasi provider di attestazioni personalizzate sia installato in tutti i server della farm dei servizi in cui viene eseguito il Servizio query di ricerca e impostazioni sito. Se non si procede in questo modo, le attestazioni personalizzate degli utenti non potranno essere valutate e quindi non verranno restituiti risultati di ricerca.
Questo scenario era molto interessante e ha richiesto una grande attività in termini di risoluzione dei problemi da parte di diversi personaggi che abbiamo qui... soprattutto del mio brillante fratellino Luca che ci ha aiutati a superare l'ultimo ostacolo, ma anche di Sanjeev e Michael P. Grazie a tutti per averci aiutati a comprendere meglio questa questione.
Questo è un post di blog localizzato. L'articolo originale è disponibile in When Do You Need to Install a Custom Claims Provider for Search in SharePoint 2010.