Security cmdlets (FAST Search Server 2010 for SharePoint)

Applies to: FAST Search Server 2010

Microsoft FAST Search Server 2010 for SharePoint provides a full set of cmdlets to manage and control item level security through the FAST Search Authorization (FSA) component. By using item level security, users only gain access to search results that they are entitled to see.

FAST Search Authorization

Item level security is enforced in two phases:

• Phase 1: Indexing - Content repositories are traversed and indexes are created. Authorization information is added to each item’s authorization managed properties (the item’s ACL, or access control list), identifying users and groups that are granted or denied access to the item.

• Phase 2: Searching - A user submits a query and the indexes are used to determine search results. In this phase, 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 is created by FSA based on the user’s specific content permissions. By checking item managed properties (item ACLs which define who has permissions to view each item) against that user’s search security filter, inappropriate search results are filtered out.

FSA has two components: the FSA manager (one per FAST Search Server 2010 for SharePoint system) and the FSA worker (one on each server that processes queries).

• The FSA manager service receives security changes from indexing connectors and pushes the updates to all the query processing nodes in the system. The FSA manager also keeps the security-related configuration of these nodes consistent by administering the FSA workers and synchronizing changes across the nodes.

• The FSA worker is part of the Query and Result Service (query processing node). FSA workers generate user search security filters based on user credentials. To do this, the FSA worker obtains group membership information for users from the FSA user stores by using principal aliasing to map users/groups from one store to another.

In this section:

• Manage general FAST Search Authorization settings

• Manage claims-based security user stores

• Manage Lotus Notes security user stores

• Manage principal alias mapping

Manage general FAST Search Authorization settings

There are many times when you must check or change general configuration settings for FAST Search Authorization (FSA). Several cmdlets address general settings such as log file configurations and system defaults.

Cmdlets for general FAST Search Authorization settings

Use these cmdlets to help manage item level security in FAST Search Server 2010 for SharePoint:

Manage claims-based security user stores

FAST Search Server 2010 for SharePoint supports claims-based authentication, which is a set of operations that establishes trust relationships between claims providers and applications. Claims authentication foregoes the need to connect to a particular enterprise directory for looking up user identities. Instead, a user's request arrives with all the identity details that the application needs. These identity attributes may include name, e-mail address, membership, etc., and is called a claim. When a claim arrives, the user has already been authenticated, and FSA makes an access control decision based on that claim which is provided by the SharePoint front-end.

FSA works with security user stores, which are logical groupings of users, groups, and content permissions that serve as security gateways to third-party content repositories to help protect their content from unauthorized access. A claims user store is created as the default user store when you decide to work with claims authentication.

Claims user store cmdlets

Use these cmdlets to manage your claims user stores:

Manage Lotus Notes security user stores

A user store in FAST Search Authorization (FSA) 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. A Lotus Notes user store caches user credentials for Lotus Notes database collections.

A Lotus Notes user store is used by FSA to generate a user search security filter. This filter is attached to the user’s query to enforce access control that is based on the user’s credentials. Before you run the FAST Search Lotus Notes user directory connector, you must create a new Lotus Notes user store that will be populated with user and group information downloaded from your Lotus Domino server.

Lotus Notes user store cmdlets

Use these cmdlets to help manage Lotus Notes user stores:

Manage principal alias mapping

Principal aliasing defines equivalences between user stores.

When group expansion information is requested during user security filter generation, FAST Search Authorization (FSA) works through each user store to gather all the security IDs that apply to the user performing the query. Many users exist in multiple user stores. For example, a Windows user may have a Lotus Notes account that is a different ID. To narrow the query results, FSA must know the user's IDs and groups in all stores. FSA includes a process that is known as principal aliasing that maps users/groups from one user store to their equivalent IDs in another user store. Principal aliasing facilitates the gathering of security IDs, regardless of which user store the user or group is authenticated to. For example, you can map the user jbrown in a claims user store to be the same as the user brownj in the Lotus Notes user store.

There are two kinds of principal aliasing:

• XML: Uses an XML file to map each specific security ID to its equivalent security ID in another store (recommended).

• Regular expression (regex): Uses regular expression patterns to define maps from one user store to another. This kind of aliasing is used to pattern match a set of users/groups from one security store to another when their user ids are constructed following a specific pattern.

Principal aliasing cmdlets

Use these cmdlets for your principal aliasing tasks: