Back to Home | Help Center | Log Out
 Help Center
 
Help Center

Home

Crawl and Index

Serving
  Front Ends
    Output Format
    KeyMatch
    Related Queries
    Filters
    Remove URLs
    OneBox Modules
  Query Settings
  OneBox Modules
  Document Preview Module
  Result Biasing
  Dynamic Navigation
  Suggestions
  Access Control
  Head Requestor Deny Rules
  Policy ACLs
  Universal Login
  Universal Login Auth Mechanisms
    Cookie
    HTTP
    Client Certificate
    Kerberos
    SAML
    Connectors
    LDAP
  Universal Login Form Customization
  Flexible Authorization
  Alerts
  Language Bundles

Status and Reports

Connector Administration

Social Connect

Cloud Connect

GSA Unification

GSAn

Administration

More Information

Serving > Access Control

Use the Serving > Access Control page to perform the following tasks:

Before Starting this Task

Before configuring access control for authorization, read the "Authentication/Authorization for Enterprise SPI Guide."

Selecting an HTTP Basic Authentication Challenge Option

Use these settings to define when the search appliance challenges a user for a user name and password when HTTP Basic authentication is used. The following table describes the options for HTTP Basic challenges.

Option Description
Never Select this option if Google Enterprise Support has advised you to do so. It completely disables the search appliance's ability to challenge the user for HTTP Basic Authentication.
Automatic - only if prompt needed Google recommends selecting this option. Challenge the user only when the search appliance assumes it needs a username and password to complete authentication.
Always Select this option if Google Enterprise Support has advised you to do so. Always challenge the user by way of HTTP Basic authentication, regardless of other authentication settings.

Enabling the Search Appliance to Record User Identities for Queries

The search appliance can record the user identity for a secure query when the user is authenticated with a verified identity. Enabling this option will set the search appliance to record the user identity (if available) for each query and display user identities in search logs and in serving logs. After you enable this option, the search appliance begins recording user identities for subsequent queries.

You can define, generate, or view a search log by using the Status and Reports > Search Logs page in the Admin Console. You can view serving logs by using the Status and Reports > Serving Logs page.

To enable recording user identities in search logs and serving logs:

  1. Click the check box for Record user identity in Search Logs and Serving Logs.
  2. Click Save Settings.

To disable recording user identities in search logs and serving logs:

  1. Clear the check box for Record user identity in Search Logs and Serving Logs.
  2. Click Save Settings.

Enabling Authentication for User Results

User results give users the capability to add search results for certain keywords in a specific front end. User results cause designated documents always to appear on the results pages for specified keyword searches performed in the front end. To configure user results, use the Social Connect > User Results page.

Enabling authentication for user results requires a user to be properly authenticated with a verified identity before adding, editing, or removing user results. If authentication for user results is enabled, and the user is not logged in with a proper verified identity, the user cannot add, edit, or delete user results. If authentication for user results is not enabled, users are not required to be properly authenticated before adding, editing, or removing them.

To enable authentication for user results:

  1. Click the check box for Require authentication for User Results.
  2. Click Save Settings.

To disable authentication for user results:

  1. Clear the check box for Require authentication for User Results.
  2. Click Save Settings.

Authorization SPI

Complete the Authorization SPI section if you have implemented an authorization service using the authorization (AuthZ) SPI. If Flexible Authorization is enabled, the Authorization SPI is inactive. In this case, to configure SAML Authorization, use the Serving > Flexible Authorization page instead.

Before using the Authorization SPI, you must configure the search appliance to crawl secure content. You can crawl secure content through one of the following mechanisms:

  • For content that requires HTTP Basic Authentication or NTLM HTTP credentials, set up the crawl under Crawler Access.
  • For content that requires a Forms Authentication rule to authenticate via a single sign-on (SSO) server, set up the crawl under Crawl and Index > Forms Authentication.
  • For content that requires a certificate authority (CA) for authentication, check the SSL settings screen to make sure that Server Certificate Authentication is enabled and that the search appliance is configured with a valid SSL certificate. For more information on certificate authorities, refer to SSL Settings.

The Authorization SPI section contains a checkbox for using batched SAML authorization requests (Use batched SAML Authz requests). You can use batched SAML authorization requests only under the following conditions:

  • Your SAML provider supports the Google SAML batch authorization extension.
  • Your system has not been using SAML in any previous Google Search Appliance software version.

If your system does not meet these conditions, do not use batched SAML authorization requests.

To complete the Authorization SPI section:

  1. Enter the URL of the service so that the system can access the service when authorization is needed.
  2. If you want to use batched SAML requests and your system meets the conditions described in this section, click the Use batched SAML Authz Requests checkbox.
  3. Click Save Settings.

The Authorization SPI section contains an AuthZ Log button. Click AuthZ Log to download internal search appliance logs for use when troubleshooting.

Setting Authorization Parameters

For each user who performs a search query that involves secure content, the search appliance first determines the relevant URLs and then determines whether the user has access to the content. The search appliance makes an authorization request to the appropriate web servers and then stores the authorization data. The search appliance uses the cached authorization information for subsequent searches, making those searches faster.

The following table explains the parameters that control the time allowed for authorization requests and the cache that controls the returned information. The default values are suitable for most environments. It is strongly recommended that you avoid tuning these parameters. If you need to improve search response time for the end user, it is a good idea to first consider improvements to web servers.

The following table lists the parameters that are standard to the search appliance. These parameter values apply whether or not you are using the authorization SPI.

Parameter Description Default Value
Query Processing Time

The search appliance processes authorization requests in batches. This parameter specifies, in seconds, how long the search appliances waits to fully process multiple batches of authorization requests. For example, if you have slow content servers, it might take the search appliance 5 seconds to process a single batch of requests. A 20-second Query Processing Time
setting would enable the search appliance to process at least four batches of authorization requests.

The parameter represents the maximum amount of time in seconds that the search appliance waits for multiple batches of authorization requests to complete. The value must be a positive number and the value should be larger than the value for the timeout for a batch of authorization requests, to ensure that the authorization requests can be completed.

Setting the parameter to a larger value enables the search appliance to process more batch requests for authorization. However, if a content server is unresponsive, performance will be negatively affected.

 20
Timeout for a batch of authorization requests The search appliance processes authorization requests in batches. This parameter specifies, in seconds, how long the search appliance waits to fully process authorization for a single batch of requests. When a batch of requests time out, the search appliance uses the results that it received and processes another batch of URLs, if it has sufficient time before it displays results to the user. You can use this value to limit the time that the search appliance waits for responses from a slow or unresponsive server.

Because a batch can contain URLs on different servers, the search appliance separately sends the requests from the same batch to the servers. Those individual requests are governed by a different timeout value, which follows.

This value must be a positive number. The value for this batch timeout should be larger than the value for individual requests, to ensure that individual requests in the batch have sufficient round-trip time.

5
Timeout for individual authorization request This parameter specifies, in seconds, how long the search appliance waits for the response to a single authorization request to a web server.

If you tune this parameter, consider that if you shorten the timeout value, slow servers may unable to respond to authorization requests in time. User results could be incomplete and skewed toward content on the fast servers. In contrast, if you lengthen the timeout value, slow web servers can provide additional results but users will experience longer response times.

This value must be a positive number. It should be smaller than the value for batch timeouts. If you increase this value, you might need to also increase the batch timeout value.

 2.5
Maximum number of concurrent authorization requests per server This value, also called hostload, specifies how many concurrent requests the search appliance can send to a single server. This parameter helps prevent overloading of servers. 10
Duration of authorization cache entry This parameter specifies how long the search appliance maintains an authorization entry, in seconds. This value should be sufficiently large to encompass a user's typical search session.

The value can be any positive integer. A value of zero (0) disables the cache and negatively affects performance.

3600
Enable late binding for Policy and Per-Url-Acl Select this option to enable late binding for policy ACLs or per-URL ACLs. In some instances, you might not want to to use early binding for allow decisions, for example, if the policy ACLs or per-URL ACLs in the index don't reflect the latest changes. For situations like this, you can enable late binding for policy ACLs and per-URL ACLs. If Flexible Authorization is enabled, this option is inactive. Not enabled

The following table explains the parameters that control how the search appliance handles unresponsive servers. A server can be unreachable because it is down or because it is overloaded and refusing new connections.

Parameter Description Default Value
Enable cache of unreachable hosts Select this option to enable the search appliance to maintain information about servers that do not respond to authorization requests. This information ensures that the search appliance avoids making repeated failed requests to the same server. Not enabled
Timeouts permitted before host is considered unreachable

This parameter specifies the number of times the search appliance attempts to contact an unresponsive server before adding it to the cache of unreachable hosts. Fluctuations in server traffic might cause a certain normal number of timeouts without indicating system failure. The value should allow for multiple failed attempts to contact a server.

The value can be any positive integer.

100
Timeout measurement period

This parameter specifies, in seconds, the timeframe during which the Timeouts permitted parameter is applied. For example, the default values permit 100 timeouts during a 300 second (five minute) measurement period. The value should be large enough to accommodate short-lived server unavailability.

The value can be any number of seconds.

300
Duration of unreachable host cache entry This parameter specifies, in seconds, the length of time that each item is maintained in the cache.

The value can be any number of seconds.

 600

You can click the Clear Caches button to immediately remove the authorization and unreachable host information. Use this button periodically to keep the authorization cache fresh.

For More Information

For more information about access control, see Administration > LDAP Setup and Crawl and Index > Crawler Access.

 
© Google Inc.