Google Search Appliance Security - Manual (Page 13)

13
Authentication Mechanism when user ID is not required (Head Requests)
Cookie This is the most common situation; the search appliance forwards user cookies to
validate access rights. Forms authentication is required. Cookie Cracking is not
needed as a user ID is not required. The rule is configured under Universal Login
Authentication Mechanism > Cookie.
HTTP An HTTP Basic/NTLM rule must be configured. The communication between the
end user browser and the search appliance is in fact Forms authentication instead of
using HTTP Basic authentication protocol. The rule is configured under Universal
Login Authentication Mechanism > HTTP.
Kerberos An HTTP Basic/NTLM rule must be configured. The communication between the
end user browser and the search appliance is in fact Forms authentication. The rule
is configured under Universal Login Authentication Mechanism > Kerberos.
Mapping authentication to authorization
Most of the time, you only need to select one authentication mechanism to verify users. You can
configure multiple authentication mechanisms, but what are the implications, and why would you need
them? Here are some rules to remember:
● When there are multiple Credential Groups, you will need to select one mechanism for each.
They can be of the same type, for example, two forms authentications or two SAML
authentications. Or they can be different:; one is forms authentication, and another is Kerberos.
● You can also configure multiple authentication mechanisms for the same Credential Group. This
is a less common usage. The exception is when a connector is used for group resolution. In this
case, one authentication mechanism (most likely silent) verifies the search user, and the
connector resolves group membership for ACL authorization. We will discuss more in later
chapters.
● All the authentication mechanisms will be fired. When two authentication mechanisms are defined
for one Credential Group, the second will be fired up even if the first rule has been satisfied with a
verified user ID.
To map authentication to authorization, the search appliance uses a feature called “flexible authorization”,
which is similar to a routing table for authorization mechanisms. It allows the administrator to configure
the authorization process for documents per URL pattern as they see fit for their deployment. Flexible
Authorization is managed through configuring authorization rules. A rule would consist of the following:
the content to which the rule applies (defined by URL pattern), an identity that maps the rule to a
credential rule or authentication mechanism, and other information specific to the authorization
mechanism.
Most of the time, you don’t have to make changes to the Flexible Authorization settings. The default
settings would work. It’s a routing table where you can mix and match authentication to authorization, but