Search Google Code

Managing Search for Controlled-Access Content: Overview

Google Search Appliance software version 4.6
Google Mini software version 4.6
Posted July 2007


The Google Search Appliance and the Google Mini make documents on your domain discoverable through search. In addition to public content that is available to everyone, the search appliance can crawl and index documents that require a login and password or another form of authentication. To protect confidentiality at serving time, the search appliance determines whether the user performing the search is authorized to view each document before it displays results.

For instance:

As the search appliance administrator, you must configure the Google Search Appliance or Google Mini to support these kinds of situations.

Table of Contents

  1. Overview
    1. Table of Contents
    2. About this Guide
    3. Which Sections of This Guide Should I Read?
    4. Comparison Between Google Search Appliance and Google Mini Capabilities
  2. Crawl, Index, and Serve
    1. Authentication, Authorization, and Controlled-Access Content
    2. Crawl and Index for Controlled-Access Content
    3. Secure Content and Public Content
    4. Serve for Controlled-Access Content
    5. Digital Certificates and Certification Authorities
    6. How to Exclude Controlled-Access Content Sources from Search
  3. Use Cases
    1. Use Case 1: HTTP Basic or NTLM HTTP Controlled-Access Content with Public Serve
    2. Use Case 2: HTTP Basic or NTLM HTTP Controlled-Access Content with Secure Serve
    3. Use Case 3: Cookie Site or Forms-based Authentication with Public Serve
    4. Use Case 4: Forms-based Authentication with Cookie Forwarding for Secure Serve
    5. Use Case 5: Forms-based Authentication with Proxied Login for Secure Serve
    6. Use Case 6: Forms-based Authentication with User Impersonation for Secure Serve

About This Guide

This guide is intended for the search appliance administrator and developers who need to understand authentication and authorization for the Google Search Appliance and Google Mini. It explains how the Google Search Appliance and Google Mini make controlled-access content available through search, describes how to configure authentication and authorization, and demonstrates how to make controlled-access content available to authorized users in your organization.

Which Sections of this Guide Should I Read?

This guide helps you to answer the following questions:

Because some methods of accessing controlled-access content do not support secure serve, the answers to these questions depend on your existing access control infrastructure, and whether your content sources require secure serve.

The following table explains which sections in this guide are most relevant for each access method, and provides links to those sections.

Access Method Search Appliance Type Access Type Suggested Crawl Method Suggested Serve Method
HTTP Basic or NTLM HTTP Google Search Appliance

Google Mini 		Public or secure Crawler Access Pass user credentials and optionally authenticate with LDAP
Single login domain: one set of domain credentials provides access to all content, but the login form uses frames or Javascript. Google Search Appliance only
Public or secure Forms Authentication Forms Authentication with an external login server
Single login domain: one set of domain credentials provides access to all content. The login form is plain HTML. Google Search Appliance only Public or secure Forms Authentication Forms Authentication with cookie forwarding
Single login domain: one set of domain credentials provides access to all content, but cookies are subject to IP restrictions or you have multiple cookie domains. Google Search Appliance only Public or secure Forms Authentication Forms Authentication with user impersonation
Multiple login domains: more than one set of credentials are required to provide access to all content. Google Search Appliance only Public only Cookie Sites No secure serve with this method
Multiple login domains: more than one set of credentials are required to provide access to all content. Google Search Appliance only Public or secure Crawler Access or
Forms Authentication		 SAML Authorization with authentication through LDAP, x.509 certificates, or the SAML Authentication SPI

Back to top

Comparison Between Google Search Appliance and Google Mini Capabilities

This section provides an overview of the authentication and authorization methods that are supported by the Google Search Appliance and the Google Mini, and lists key reference sections in this guide for those topics.

The following table lists supported methods for confirming a search appliance's credentials during crawl and index. To understand how these methods are implemented, see Authentication, Authorization, and Controlled-Access Content, Crawl and Index for Controlled-Access Content, Secure Content and Public Content.

Search Appliance's Access to Content Description Google Search Appliance Support Google Mini Support
HTTP Basic The search appliance stores a username and password for each URL pattern. Credentials are sent as plain text unless the URL specifies HTTPS.

For examples using HTTP Basic, see Use Case 1 (Public Serve) and Use Case 2 (Secure Serve). 		Yes Yes
Windows Authentication
(NTLM HTTP v1)
(NTLM HTTP v2)
 The search appliance stores a username and password for each URL pattern. Use this method to crawl and index content on Microsoft IIS web servers that use Integrated Windows Authentication, which includes NTLM. The IIS web server must support the HTTP/1.0 keep-alive connection token.

For examples using NTLM HTTP, see Use Case 1 (Public Serve) and Use Case 2 (Secure Serve).
Yes Yes
Cookie forwarding via Cookie Sites The search appliance records a cookie for each URL pattern. These credentials grant access for the search appliance to crawl and index all content via cookie forwarding. Content from a cookie site crawl is always labeled as public content. If the cookie expires, cannot be forwarded, or must be served as secure content, use HTML-based Forms authentication.

For examples using Cookie Sites, see Use Case 3 (Public Serve).

Yes No
Cookie forwarding via HTML-based Forms Authentication The search appliance performs user impersonation and obtains a cookie for each URL pattern. These credentials grant access for the search appliance to crawl and index all content that requires authentication via a Single Sign-on session cookie.

For examples using Forms Authentication, see Use Case 3 (Public Serve) and Use Case 4, Use Case 5, Use Case 6 (Secure Serve). 		Yes No
X.509 certificate authentication When performing crawl over HTTPS, if the content server requests the search appliance's certificate during the SSL handshake, the search appliance responds with a digital certificate.

For more on X.509 certificate authentication, see Digital Certificates and Certification Authorities. 		Yes Yes

The following table lists supported methods for confirming a user's identity during serve. To understand how these methods are implemented, see Serve for Controlled-Access Content.

User's Access to Content Description Google Search Appliance Support Google Mini Support
HTTP Basic
NTLM HTTP v1
NTLM HTTP v2 		The search appliance stores the user's credentials in an encrypted search appliance session cookie on the user's computer. This method does not perform any password verification: if the user enters their credentials incorrectly, they will be unable to view secure results for the duration of their session.

For examples using HTTP Basic and NTLM HTTP, see Use Case 1 (Public Serve) and Use Case 2 (Secure Serve). 		Yes Yes
HTTP Basic
NTLM v1
NTLM v2
with
Directory Service Integration (LDAP) 		The search appliance validates the user's credentials against an LDAP server using either HTTP Basic or SSL. If the credentials are valid, the search appliance creates an encrypted search appliance session cookie on the user's computer. Use this method for integration with an ActiveDirectory server.

In Serve for Controlled-Access Content, see HTTP Basic or NTLM HTTP with Authentication Against an LDAP Server. For examples using HTTP Basic and NTLM HTTP, see Use Case 1 (Public Serve) and Use Case 2 (Secure Serve).
Yes Yes
HTML forms-based authentication by cookie forwarding The search appliance performs a proxied login on the single sign-on (SSO) server and obtains a session cookie for the user. The user can continue to search without re-authenticating as long as the session cookie is valid.

This method requires the search appliance and the SSO server to be on the same cookie domain, and requires the cookie issued by the server to be free of any IP restrictions. You cannot use this method if the login form contains javascript or frames.

In Serve for Controlled-Access Content, see Enabling Forms Authentication Through Cookie Forwarding. For examples using Forms Authentication with Cookie Forwarding, see Use Case 3 (Public Serve) and Use Case 4 (Secure Serve). 		Yes No
HTML forms-based authentication by using an external login server The search appliance redirects the user to a script on an external login server to perform authentication. The user can continue to search without re-authenticating as long as the session cookie is valid.

This method requires the search appliance and the external login server to be on the same cookie domain, and requires the cookie issued by the server to be free of any IP restrictions.

In Serve for Controlled-Access Content, see Enabling Forms Authentication Through an External Login Server. For examples using Forms Authentication with an External Login Server, see Use Case 3 (Public Serve) and Use Case 5 (Secure Serve). 		Yes No
HTML forms-based authentication by user impersonation The search appliance displays its copy of the login form to the user and obtains the user's login name and password. The search appliance then impersonates the user and requests a session cookie on behalf of the user. The search appliance uses this cookie each time that the user performs a search.

This method does not require the search appliance and the external login server to be on the same cookie domain, and is unaffected by IP restrictions on the server's cookie. However, the user must log in twice: once for the query performed on the search appliance, and once for the server that hosts the content.

In Serve for Controlled-Access Content, see Enabling Forms Authentication Through User Impersonation. For examples using Forms Authentication with User Impersonation, see Use Case 3 (Public Serve) and Use Case 6 (Secure Serve). 		Yes No
Authentication and Authorization SPI The search appliance sends SAML messages to an Identity Provider and a Policy Decision Point to verify the user's credentials and authorization to view secure content. This method requires you to set up an Identity Provider and Policy Decision Point that can handle the SAML messages from the search appliance's Authorization and Authentication SPI.

In Serve for Controlled-Access Content, see The SAML Authentication and Authorization Service Provider Interface (SPI).		 Yes No
Authorization SPI
with
Directory Service Integration (LDAP) 		The search appliance validates the user's credentials against an LDAP server, and sends a SAML Authorization Request to a Policy Decision Point to determine the user's authorization to view secure content.

This method requires you to set up a Policy Decision Point that can handle the SAML authorization request from the search appliance's Authorization SPI.

In Serve for Controlled-Access Content, see HTTP Basic or NTLM HTTP with Authentication Against an LDAP Server and The SAML Authentication and Authorization Service Provider Interface (SPI).
 Yes No
Authorization SPI with X.509 certificate authentication The search appliance checks the user's SSL certificate to verify authentication, and sends a SAML Authorization Request to a Policy Decision Point to determine the user's authorization to view secure content.

This method requires you to set up a Policy Decision Point that can handle the SAML authorization request from the search appliance's Authorization SPI.

See Digital Certificates and Certification Authorities, and in Serve for Controlled-Access Content, see The SAML Authentication and Authorization Service Provider Interface (SPI). 		Yes No

The following table lists supported methods for confirming a user's authorization to view secure content in their search results.

User's Access to Content Description Google Search Appliance Support Google Mini Support
HTTP Basic
NTLM HTTP v1
NTLM HTTP v2 		For secure content that was crawled using HTTP Basic or NTLM HTTP authentication, the search appliance performs an HTTP HEAD request for the document, using the credentials obtained for the user during serve authentication. If the request is successful, the search appliance authorizes the user to view the document in their search results. Consider forcing secure serving to ensure that the user's identity is always sent securely over HTTPS during server.

HTTP HEAD requests are defined in section 9.4 of the HTTP protocol specification. This guide does not discuss HEAD requests in detail. 		Yes Yes
HTML forms-based authentication For secure content that was crawled using Forms Authentication, the search appliance performs an HTTP GET request for 0 bytes of the document, using the credentials obtained for the user during serve authentication. If the request is successful, the search appliance authorizes the user to view the document in their search results.

HTTP GET requests are defined in section 9.3 of the HTTP protocol specification. This guide does not discuss GET requests in detail.		 Yes No
Authorization SPI For secure content that was crawled using the SAML Authorization SPI, the search appliance sends a SAML authorization request to the Policy Decision Point, using the identity obtained for the user during serve authentication. If the request is successful, the search appliance authorizes the user to view the document in their search results.

In Serve for Controlled-Access Content, see The SAML Authentication and Authorization Service Provider Interface (SPI).

Yes No

 

Last modified: