FAST Search Authorization (FSA) data flow
Applies to: FAST Search Server 2010
The FAST Search Authorization (FSA) solution for securing search content includes the following components and processes.
FSA data flow
.gif "FAST Search Authorization data flow overview")
FSA helps secure search content at item processing time and during search activities.
Phase 1: Item processing and indexing
A content connector extracts items, access control information (ACLs), and user directory information from a source system, such as SharePoint. The content and item ACL are fed into an item processing pipeline for indexing. During the indexing phase, the document ACL is indexed exactly like any other field in the document and lists the users and groups that can read the documents. Depending on the security model of the source system, you can also include deny-lists.
A user store is a logical grouping of users, groups, and content permissions that serves as a security gateway to a third-party content repository to help protect its content from unauthorized access. If your search implementation includes content from several different providers, you may have to create multiple security user stores. A claims user store is created as the default user store when you work with claims authentication.
Phase 2: Searching
On the search side, FSA enforces security trimming, limiting search results based on the identity of the user who submitted the query. The Query and Result Service (query processing node) accepts a user’s query together with the user’s claim. When an incoming search request passes through the query transformation pipeline, FSA expands the request with group membership information for that query user, building a user search security filter that specifies content permissions for that specific search user. The QRServer intersects the query with the user’s search security filter, checking item ACLs against the filter to weed out items that the user is not allowed to access. When the search is run, it returns a subset of items which the user is authorized to see.
Lotus Notes content
To include Lotus Notes content in the FAST Search Server 2010 for SharePoint index, you must first create a Lotus Notes user store. The FAST Search Lotus Notes connector reads users and groups from a Lotus Notes system and populates the FSA Lotus Notes user store with user credentials and content permissions for Lotus Notes database collections. The query processing server uses this information to create a user security filter that lets Lotus Notes indexed content to be returned to the user at query time. You must match the ID of the Lotus Notes user store with the ID that you specify in the FAST Search Lotus Notes connector configuration. See Configure the FAST Search Lotus Notes connector for more information.
Principal aliasing
FSA uses a process that is known as principal aliasing to map information in the user’s claim to their equivalent IDs in the Lotus Notes user store. For example, you can map a user’s claim with the value of jbrown to be the same as the user brownj in the Lotus Notes user store. The FAST Search Lotus Notes connector generates a mapping file which you can upload to FSA. The Lotus Notes mapping file is an XML file that instructs the FSA worker how to map a claim value to its equivalent ID in the Lotus Notes system. This mapping helps create a user’s security filter that lets indexed Lotus Notes items to be returned to the user at query time. See Prepare FAST Search Authorization for use with the FAST Search Lotus Notes connector for more information.