Google Search Appliance Security - Manual (Page 7)

7
Content Acquisition
The acquisition generally comes in the following forms. Note that the authentication protocol used would
have to be what’s supported by the content source. However, the content acquisition would usually allow
different authorization mechanisms to be used.
Possible authorization
mechanisms for serving Notes
Direct Crawl ACL, Head Request, SAML
Authorization It may involve developing a custom proxy server
for extra processing
Feeds ACL, Head Request, SAML
Authorization A simple, custom one-off implementation
Connectors ACL, Connector
Authorization It could either be an off the shelf connector, or a
custom connector to be developed
Single vs. Multiple identities
By examining all the content sources, you should be able to answer a very important question: Is one
(default) Credential Group enough? This determines the model for serve time authentication. When there
are multiple identities per user, you probably need to define multiple Credential Groups. Different
authentication protocols for different content sources do not mean multiple identities. For example, one
content source could be using a forms based authentication while another uses Kerberos. However, if the
same Active Directory is used as the user directory for both systems, there is only one identity per user.
Only if user information is stored in different repositories, there might be multiple identities needed by
GSA. Still, there are two exceptions:
● If one user directory is a replicate of another, there is still one identity per user. Hence one
Credential Group is enough. For example, when Documentum is integrated with Active Directory,
one approach is for all the users to be replicated in Documentum database.
● If there is a strict matching of user names from two user directories, one Credential Group is
enough as long as you put in place a user identity translation service—maybe as part of the
authorization process.