Google Drive

To use the Google Drive Search Federation you must create an App through Google, and authorize the App to make requests on behalf of users on your domain. No extra privileges, other than a Google account, are required to create a Google App. Authorizing the App will require Admin privileges for the Google domain you wish to federate. Google is constantly enhancing and improving their services, so some screens may have changed.

When synced to a local file system, Google Drive may be indexed just like other local folders. This may be done by an administrator with access to the file system or by a user using the Perceptive Anywhere agent to index their desktop.

Prerequisites

In order to use this federator, you must have .NET 3.5 installed on the machine hosting Perceptive Enterprise Search.

Creating a Google App

All Google Apps are managed at http://cloud.google.com/. Google Apps belong to a parent project, which you must create first.

Click on Create Project and choose a name for your project. Google will automatically assign a unique "Project ID". The "Project name" and "Project ID" are not used by Perceptive Search.

Google may require "SMS Verification" to create a new project. If you recieve the following box, just follow the instruction from Google.

Once you complete the new project dialog and any account verification steps required, you should be on the new project's overview page.

Next, you must allow the project to make API calls using the Drive API. To do this, click on APIs & auth then on APIs. You'll be presented with a list of all Google APIs. From this list, find Drive API and click ON/OFF. You'll be presented with a dialog to accept Google's Terms of Service.

Once you have enabled the Drive API, it will move to the top of the list and switch from OFF to ON.

Now that the project is created and has access to the Google Drive API, you must configure client credentials. Select APIs & auth, if not already expanded, then click on Credentials.

Click on Create New Client ID to generate an OAuth2 Service Account Client ID.

Select Service account and click on Create Client ID. After a few moments, you will be given an opportunity to download the private key (.p12 file).

Make a note of the Service Account email address provided, as it will be required by the Google Drive Federator configuration wizard. Also make a note of the Service Account Client ID as it will be required for the next section "Authorizing the Google App on your Google Domain".

Authorizing the Google App on your Google Domain

This next step will allow Perceptive search to execute queries on behalf of the user, so that they will only get documents and files that they have access to. In order to authorize an app, you must have admin access for your Google Domain. Select Security on your Google Admin console. This page is customizable, so it may not look exactly as shown.

On the Security page, click on Advanced settings to expand the view, then click on "Manage third party OAuth Client access".

In the Client Name field, enter the client id for the service account created above. In the API Scopes field enter "https://www.googleapis.com/auth/drive.readonly.metadata" without quotes. Click to Authorize the App.

Set the Web Site to Require User Login

For the Google Drive Federator to work properly, users must log into the web site. On the administration site navigate to Home::Web Sites::Default::Security::Access Control. Under the heading Anonymous Access click the radio button next to "Users must login to access web site".

Using LDAP to retrieve email addresses

If a simple regular expression cannot map user names to email addresses (for example, user1's Google address is bob45@example.com), an LDAP mapping may be necessary. It will look up a user record using LDAP, and use the specified attribute in the record as the Google email address. Two common LDAP implementations are OpenLDAP and Active Directory.

When creating a GoogleDrive index, you will have the opportunity to specify LDAP settings on the User Configuration page. There are four required fields to connect to an LDAP server.

Server Address. The IP address or hostname of the server. If a port other than the standard port (389) is used, it must be included in this field after a colon.
Example: ldap.subdomain.example.com:636
User Filter. The user filter is the query executed to find the unique user account. It must contain enough information to return a unique result. OpenLDAP servers commonly use the uid attribute, while Active Directory servers use the sAMAccountName attribute instead. Note that any instance of %u in this field will be replaced by the result of the regular expression entered into the box at the top of the page. The string that is supplied to the regular expression has the format DOMAIN_NAME\user. If the regular expression box is left empty, that string will be substituted for any instance of %u in the user filter. Depending on what is stored in your LDAP server, you may or may not need to strip the domain name using the regular expression. Putting /^*.\\(.*)$/$1/ as the regular expression will strip the domain name, leaving only the user name.
OpenLDAP Example: (uid=%u)
Active Directory Example: (sAMAccountName=%u)
Base DN. The base DN is the node at which LDAP will start searching for the user. This will depend on your LDAP implementation. For Active Directory domains, the string specifies each part of the domain name as a node. In other implementations, the string contains the object and subdirectory of the user.
Example: subdomain.example.com could have a baseDN of DC=subdomain,DC=example,DC=com
or
OU=Users,O=ExampleDomain
Attribute containing email. This specifies the attribute returned by the LDAP query which contains the Google email address. Typically, this is the mail attribute, but it could be any other attribute contained in that user's profile on the LDAP server. If you are unable to use the mail attribute, you can repurpose another field or create a custom attribute.
Example: mail

There are two additional fields text fields: the binding user and password. If your LDAP server is configured to allow anonymous queries, then these fields are not required. Otherwise, you will need to specify the user and password used to run the LDAP query. This Microsoft Knowledge Base article describes how to enable anonymous access on Active Directory. OpenLDAP has anonymous access enabled by default.

Binding user. Active Directory users only need the user name itself, while OpenLDAP users will need to specify the user node.
Active Directory Example: admin
OpenLDAP Example: uid=admin,ou=users,o=domainname
Password. The password for the binding user specified above. It will be encrypted during storage, but will be sent in clear text if SSL is not enabled.

The last two options apply to every LDAP connection.

SSL Encryption. Specifies wether the connection should use SSL encryption during the query. It is better to use SSL if it is configured on your server. Passwords for the binding user will be sent in clear text if SSL is not enabled.
LDAP Version. Determines which version of LDAP is used. Choose whichever setting is supported by your LDAP implementation. If your server supports both, either option will work.