Google Search Appliance Managing Search for Controlled-Access Content - Manual (Page 37)

Google Search Appliance: Managing Search for Controlled-Access Content 37
2. Choose Administration > SSL Settings. Scroll down to Force secure connections when serving?.
• To return results in the protocol used by the original search query, choose No. This option is the
least secure.
• To force the search appliance to use HTTPS for secure content only, choose Use HTTPS when
serving secure results, but not when serving public results.
• To force the search appliance to use HTTPS for all content, choose Use HTTPS when serving
both public and secure results. This option is the most secure.
3. Click Save Setup.
Using Silent Authentication
With silent authentication, users are authenticated without being directed to a login page. The following
table lists methods that provide silent authentication. Some methods produce a primary verified
identity (see “Primary Verified Identity” on page 17). Because a primary verified identity is required for
policy ACLs (see “Policy Access Control Lists” on page 40), these methods can be used with them. The
methods that do not produce a primary verified identity cannot be used with policy ACLs, SAML, or
connectors.
Using Cookie Cracking
If a credential group requires a user name for an authenticated user, you can implement silent
authentication for content in the credential group (see “Credential Groups” on page 16) by using cookie
cracking. Google recommends using the Require a user-name? option (see “Require a User-Name
Option” on page 19) when you are using policy ACLs, authorization results caching, SAML authorization,
or connector authorization. When you use cookie cracking, inbound cookie forwarding (from the
content server to the search appliance) provides a username and or group.
To implement cookie cracking, if a sample URL check for user credentials is successful, the web server
that runs the sample URL page generates the following response HTTP header (in addition to the
standard headers):
X-Username:value
X-Groups: value1, value2
where value becomes a verified identity for the credential group that is associated with the sample
URL.
Method Description
Cookie-based If Require a user-name? (see “Require a User-Name Option” on page 19) is not
checked, inbound cookie forwarding provides silent authentication without a
primary verified identity; it cannot be used with policy ACLs, SAML, or
connectors.
If Require a user-name? (see “Require a User-Name Option” on page 19) is
checked, then silent authentication can only be achieved with cookie cracking
(see “Using Cookie Cracking” on page 37).
Kerberos Authentication is always silent, produces a verified identity, group data can only
from the internal GData-based database.
SAML Can be silent, depending on how the SAML server is configured, produces a
primary verified identity, can return group data.
x.509 https client
certificate Authentication is always silent, always produces a primary verified identity,
group data can only from the internal GData-based database.