How the authorization spi works – Google Search Appliance Authentication/Authorization for Enterprise SPI Guide User Manual
Page 19

Google Search Appliance: Authentication/Authorization for Enterprise SPI Guide
19
When a user performs a search over access-controlled documents, the user must first authenticate to
the search appliance. This allows the search appliance to reference the user’s identity when making
authorization checks, and to include the search user’s identity in search logs.
There is an option to turn off cache links and snippets for access-controlled documents. This allows the
administrator to assess the risk of storing access-controlled documents on the search appliance.
As with authentication, the protocol used between the search appliance, the browser, and the PDP is
taken from SAML 2.0, an XML-based standard, whose primary use case is inter-domain single sign-on.
For example, suppose a user is logged in at organization A, and wants to access content at organization
B. Instead of forcing the user to log in again, SAML provides a way for the SSO system at A to vouch for
the user by communicating with the SSO system at B. In our scenario, the PDP acts as organization A,
while the search appliance acts as organization B.
Figure 9: SAML Authorization calls between the Google Search Appliance and the PDP.
Version 6.0 provides batched SAML authorization requests, which you can use under the following
conditions:
•
Your SAML provider supports the Google SAML batch authorization extension.
•
Your system has not been using SAML in any previous search appliance software version.
How the Authorization SPI Works
When the search appliance needs to check whether a search user has access to a URL, it creates a
message containing the user identity and the URL, and sends it to an authorization server. This
authorization server is the Policy Decision Point (PDP), a service provided by the customer. In response
to authorization check requests, the Policy Decision Point responds with a message that says either
“Permit,” “Deny,” or “Indeterminate.” (these terms are defined by the SAML standard).
For each URL in a search results list, the search appliance issues an
element, containing the identity of the user and the URL in question, to the Policy Decision Point. The
PDP sends back a
whether the user is authorized for the URL. These messages are exchanged using the SAML SOAP
binding over HTTPS.
The format of these messages are defined by SAML, and they are sent over SOAP over HTTPS. How the
SAML messages are embedded in SOAP is also defined by SAML, as the “SAML SOAP binding”. For
complete details, please refer to the SAML standard.
When the search appliance makes an authorization check, it caches the result. The time that this
information is valid is configurable in the Admin Console.