Security for federation (Search Server 2008)

Applies To: Microsoft Search Server 2008

Topic Last Modified: 2008-10-02

This article explains the security best practices for the Federation feature of Microsoft Search Server 2008. It should be read by information technology professionals as well as system architects and search services administrators.

Search Federation Overview

Federated search enables end users to issue one query that can query one or more search engines that are compliant with Open-search 1.1 and display results from each search engine in a separate Web Part on a single search results page. These sources can be enterprise content repositories, other search engines, or portions of your content index. For more information about Search Federation, see Federated Search Overview (https://go.microsoft.com/fwlink/?LinkId=122651) and Working with federation (Search Server 2008).

Authentication Types

Several types of user authentication, per-user and common credentials, are available for Federated search. It is important to note, however, that collecting credentials requires a Web Part extension for non-Kerberos authentication types in per-user authentication. In the authentication and credentials information section of the location definition, you specify the authentication type for the federated location. The authentication type can be one of the following:

• Anonymous

  No credentials are required to connect to the federated location.

• Common

  Each connection uses the same set of credentials to connect to the federated location.

• Per-user

  The credentials of the user who submitted the search query are used to connect to the federated location.

For the common and per-user authentication types, you must also specify one of the following authentication protocols:

• Basic

  Basic authentication is part of the HTTP specification and is supported by most browsers.

  Security Note:

  Web browsers that use Basic authentication transmit passwords in an unencrypted form. By monitoring communications on your network, a malicious user can use publicly available tools to intercept and decode these passwords. Therefore, Basic authentication is not recommended unless you are confident that the connection is secure, such as with a dedicated line or a Secure Sockets Layer (SSL) connection.

• Digest

  Digest authentication relies on the HTTP 1.1 protocol as defined in the RFC 2617 specification at the World Wide Web Consortium (W3C) Web site. Because Digest authentication requires HTTP 1.1 compliance, some browsers do not support it. If a browser that is not compliant with HTTP 1.1 requests a file when Digest authentication is enabled, the request is rejected because Digest authentication is not supported by the client. Digest authentication can be used only in Windows domains. Digest authentication works with Microsoft Windows Server 2008, Microsoft Windows Server 2003, and Microsoft Windows 2000 Server domain accounts only, and may require the accounts to store passwords as encrypted plain text.

• NTLM

  User records are stored in the security accounts manager (SAM) database or in the Active Directory database. Each user account is associated with two passwords: the LAN Manager-compatible password and the Windows password. Each password is encrypted and stored in the SAM database or in the Active Directory database.

• Kerberos (per-user authentication type only)

  By using the Kerberos protocol, a party at either end of a network connection can verify that the party on the other end is the entity it claims to be. Although NTLM enables servers to verify the identities of their clients, NTLM does not enable clients to verify a server’s identity, nor does NTLM enable one server to verify the identity of another. NTLM authentication is designed for a network environment in which servers are assumed to be trusted.

• Forms

  A forms authentication cookie is nothing but the container for a forms authentication ticket. Each request passes the ticket as the value of the forms-authentication cookie and is used by forms authentication, on the server, to identify an authenticated user. However, cookieless forms authentication passes the ticket in the URL in an encrypted format. Cookieless forms authentication is used because client browsers might block cookies. This feature is introduced in the Microsoft .NET Framework 2.0.

Security trimming in Federated search

An important consideration to evaluate when using Federated search is security trimming of search results. Security trimming is a method by which returned results are filtered based on user account permissions. By default, security trimming of search results persists for results returned by the following:

• Local farm

  In scenarios where the federated location is an Open Search location and the location is configured for per-user authentication, a user's credentials are automatically passed if Kerberos authentication is being used. However, user credentials are not passed automatically for authentication protocols other than Kerberos. To ensure that results are security trimmed for the current user for these scenarios, extend the Federated Results Web part to collect user credentials. For more information, see Creating a Custom Federated Search Web Part with a Credentials UI (https://go.microsoft.com/fwlink/?LinkId=122653).

• If Kerberos authentication is not used, you also need to extend the Federated search Web parts to collect user credentials if you want to ensure that search results for OpenSearch locations (all locations other than the local farm) are security trimmed for each user.

For more information about Security for Search Server 2008, see Security and protection for Search Server 2008 and Security considerations for search (Search Server 2008).