Security considerations for indexing (FAST Search Server 2010 for SharePoint)
Applies to: FAST Search Server 2010
Topic Last Modified: 2011-02-28
Most FAST Search Server 2010 for SharePoint systems include several content sources for searching, which may include both public documents and proprietary items. For example, you may have an internal human resources database that requires restricted access. Or you may have a products database that is available for public consumption. This article discusses the implementation and management of content security at the item, or document, level.
When planning for item level security, consider the following questions:
What content will be indexed?
Is the content public or proprietary?
What organizational security policies must be implemented?
What user and group permissions are required?
How does item level security affect the search experience?
Use the information in this article to make decisions about secure content:
When source content is crawled and indexed, authorization information is added to each item’s managed properties (the item’s ACL, or access control list), identifying users and groups that are granted or denied access to the item. Item ACLs help set up item level security by tagging each item with access permissions.
When a user submits a query and the indexes find search results, the query processing service rewrites the user’s query so that the user only sees items that he is authorized to see. This security trimming is performed with the help of a user search security filter, which specifies content permissions for the user. By checking item ACLs against a user’s search security filter, unsuitable search results are filtered out, narrowing query results to only those items that the user is allowed to view.
FAST Search Authorization (FSA) is the security module in FAST Search Server 2010 for SharePoint that enforces security trimming. FSA limits user access to items in search results that they are authorized to see. When you install FAST Search Server 2010 for SharePoint, FSA is installed automatically.
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. During installation, a default claims user store is created for Microsoft repositories (Outlook, Word documents, SharePoint databases, etc.). (Claims-based authentication is a set of operations that establishes trust relationships between claims providers and applications.) When you have content from several different providers, you may have multiple security user stores (for example, you may need a Lotus Notes user store to cache credentials for Lotus Notes users). To create a user search security filter, FSA consults the user stores to determine which groups a user belongs to.
Work with colleagues who play a role in your organization’s security team to understand security policies that relate to your content databases.
Is the content public?
Is the content proprietary?
Is there a subset of items that contain confidential content?
Should item level security be defined for access by specific users and groups?
Can you map the users/groups in content databases with Windows users/groups?
Consult your search administrator to determine what guidelines must be followed to implement item level security. See Security considerations for the server farm (FAST Search Server 2010 for SharePoint) for more security planning guidelines.
Planning for item level security should be an important part of your content planning. As you consider which content sources will be crawled and indexed, consider the following:
What are the sources of the content repositories (Microsoft, Lotus Notes, external database, etc.)?
What repositories are public? Which are proprietary? Which include confidential items?
Which users and groups have permissions to access content source?
If you are not a subject matter expert, ask for help from content owners/administrators in your organization.
|Be careful not indexing new content sources before you have verified that the security permissions on the content repository are correct. This is particularly important for content sources that are not easily accessible via a browser, such as databases and file shares. Incorrect security permissions become very visible when the content has been indexed.|
See Plan for crawling and federation (FAST Search Server 2010 for SharePoint) for planning guidance on identifying, crawling, and indexing content sources.
Content permissions control access to your sites and indexed content. For Microsoft content, you will use Microsoft SharePoint Server 2010 groups, which control membership and fine-grained permissions to help provide item level security. See Security planning for sites and content (SharePoint Server 2010) for more information about the following considerations:
Planning site permissions
Determining permission levels and groups
Choosing security groups
Choosing administrators and owners
Each content source should have a user store created, to serve as a security gateway to the permissions on content in the different content sources. However, when you plan to index Microsoft content sources, you do not have to create a user store. By default, a claims user store is created and implemented for Microsoft content when you install FAST Search Server 2010 for SharePoint.
FSA generates user search security filters by accessing permissions in your user stores.
If you plan to crawl and index Lotus Notes content with the FAST Search Lotus Notes connector, additional security measures (beyond those planned for indexing Microsoft content) must be considered:
To include Lotus Notes content in a FAST Search Server 2010 for SharePoint index, you must first create a Lotus Notes user store. See Prepare FAST Search Authorization for use with the FAST Search Lotus Notes connector for detailed information.
When you run the FAST Search Lotus Notes connector, plan to generate the ssomapping.xml. This file creates principal aliasing mapping for FSA between Windows user claim values and their equivalent IDs in the Lotus Notes system. Principal aliasing is required to create comprehensive and accurate user security filters. See Configure the FAST Search Lotus Notes connector for more information.
|If you plan to use the Lotus Notes indexing connector, these planning guidelines do not apply. The Lotus Notes indexing connector maps Lotus Notes users/groups to Windows users/groups and feeds NTACL information.|
ConceptsFAST Search Authorization (FSA) overview
FAST Search Authorization (FSA) data flow
About principal aliasing
Plan for crawling and federation (FAST Search Server 2010 for SharePoint)
Configure the FAST Search Lotus Notes connector
Prepare FAST Search Authorization for use with the FAST Search Lotus Notes connector
Other ResourcesSecurity planning for sites and content (SharePoint Server 2010)
Plan authentication methods (SharePoint Server 2010)