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

Google Search Appliance: Managing Search for Controlled-Access Content 56
Serving Controlled-Access Content to the User as
Public Content
ABC Company has decided to make the search results public: the events, announce, and directory
servers control access to their content, but employees can discover the information they need by
performing a search query.
Eric is an employee of ABC Company. He wants to find an announcement about a colleague’s recent
promotion to Director. Eric opens the search page in a web browser and enters a query about “Maria
Jones director”. The search appliance performs the following steps before sending Eric to the search
results page:
1. The search appliance checks to see whether any of the content sources require authorization.
Although the search appliance had to provide credentials to index the content, the Make Public?
checkbox is selected for all of ABC Company’s content sources. All content in the index is labeled as
public: no authorization check is required.
2. The search appliance queries the index and obtains a list of relevant results for Eric’s query.
3. Eric sees search results from events.abc.int, announce.abc.int, and directory.abc.int that
match the query “Maria Jones director”. For instance, Eric finds an all-hands meeting that Maria
scheduled from events, a notice about her promotion from announce, and her office phone
number and location from directory.
When Eric clicks on one of the links in the search results page, the server that hosts the page requests a
response that includes an authentication header. If Eric hasn’t logged in elsewhere, he’ll have to enter a
username and password on a login form. Although the search appliance indexed the content as “public,”
the server still requires credentials before it displays the full document.
The next time that Eric clicks a link on his search results page, however, his browser forwards an
authentication header based on his user name and password to the server. If all the servers in this
example are on the same domain and accept the same credentials, Eric shouldn’t have to log in again
for as long as he keeps the browser open.
Use Case 2: One Set of Credentials for Multiple
Authentication Mechanisms
AlphaLyon is a multi-national corporation that has various different content servers that use different
authentication mechanisms.
• http://insidealpha.com is the URL for content protected by a single sign-on (SSO) server.
• apacheserver.alphainside.com is a server for content protected by a custom apache script that
uses cookies from the SSO system.
• comp.alpha.int is a simple web server that uses HTTP Basic authentication. This server hosts
some personnel information from North America.
• pers.def.int is a Microsoft IIS web server that uses NTLM v2 HTTP. This server hosts global
personnel information, excluding North America.
• AlphaLCM is a connector manager with one connector instance that is used to traverse and index
information (including some global personnel information) from AlphaLyon’s Documentum content
management system.
There is a single corporate-wide set of credentials for each employee.