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

Google Search Appliance: Managing Search for Controlled-Access Content 66
Search by an Unauthorized User
Eric isn’t a member of the sales team, but he’s also interested in the new AlphaLyon Product release and
wants to know when the sales figures will be posted. Eric opens the search page in a web browser and
enters the same query for AlphaLyon Product fall sales report. The search appliance performs
the following steps before sending Eric’s browser to the search results page:
1. The search appliance queries the index and obtains a list of the most relevant results for Eric’s
query. The list of potential results includes press releases announcing the new AlphaLyon Product
release, as well as sales presentations and other sales collateral materials about AlphaLyon
Product.
2. The search appliance filters the list of results as specified by the front end that applies to Eric’s
search. It applies Filters defined in Serving > Front Ends > Filters and excludes all URLs listed in
URLs from Serving > Front Ends > Remove URLs.
3. The sales collateral materials come from content sources that are labeled “secure”. Before it can
serve results for Eric’s query, the search appliance needs more information.
4. The search appliance checks to see whether Eric has provided credentials that it can use. Eric’s web
browser obtains or validates his Kerberos ticket from the network domain controller, which is
acting as a Kerberos Key Distribution Center (KDC).
5. The search appliance sends an authorization request to Eric’s web browser. Because the search
appliance is configured to force the use of SSL for secure search, the request is sent over HTTPS.
6. Because Eric’s Kerberos ticket is valid for use by the search appliance, Eric’s web browser does not
display the Universal Login Form. His query is silently authenticated through Kerberos.
7. Eric’s Kerberos ticket is used to generate an encrypted session cookie on his computer. The browser
sends Eric’s credentials back to the search appliance as an authentication header sent over HTTPS.
8. Using Eric’s cookie, the search appliance performs an HTTP HEAD request for each of the secure
documents in the list of results. If the server returns “HTTP status 401” (not authorized) for a
document, or the authorization attempt is inconclusive, the document is removed from the list of
potential results. Because Eric isn’t a member of the policy group sales, the search appliance fails
its authorization check using Eric’s credentials. It removes all of the secure sales collateral materials
from the list of potential results.
9. The search appliance creates a list of search result snippets and URLs that meet all of the following
criteria:
• URLs match Eric’s search query.
• URLs are not excluded by a filter in Eric’s front end.
• URLs are not excluded by a Remove URL in Eric’s front end.
• The URL is public or Eric has authorization to view the URL.
10. The search appliance directs Eric’s browser to the search results page that contains all public
documents that match the query “AlphaLyon product”. Eric should see results from
products.alphalyon.int and news.alphalyon.int, but unlike Salim, he doesn’t see any results
from emp.alphalyon.int, sales.alphalyon.int or customers.alphalyon.int.
The search results page doesn’t tell Eric how many search results match his query or display
“Goooooogle” links, since that reveals how many secure documents exist in the index.