With Google Search Appliance (GSA) connector framework 3.x, user group lookup is an essential part of user authorization when searching for controlled-access content, especially for early binding.
During controlled-access content search, GSA first authenticates user with the authentication mechanism configured. After the user identity is resolved, GSA will pass it to the connector for group lookup if any connector(s) are designated for group lookup. Based on the group membership information returned from group lookup, GSA will do result trimming to return … results to the user.
Quite often we would encounter issues where the search results are not expected. In order to investigate the causes, we need check user authentication, group lookup, and ACL information retrieved for controlled-access content.
GSA connector framework 3.x provides a very straightforward way to verify the user’s group membership. Here are the steps to do that:
- Create a simple XML file, say authnReq.xml with following content, and put it under Connector Manager (CM) server host:
Where myaccount is the user account you need verify, which would be the result of user authentication.
- Run the following curl command within the directory where the above file was saved :
curl -H “Content-Type: text/xml; charset=utf-8” -d @authnReq.xml -X POST http://localhost:8080/connector-manager/authenticate
Good UX Means Good Business
In a world where technology is rapidly advancing and user expectations are rising, it’s no longer enough to have an average user experience; to delight your users and surpass your competition you must strive for the exceptional.
The header directive -H “Content-Type: text/xml; charset=utf-8” can be omitted in some cases. If you do not get the results you expected, try adding it to the curl call.
- That’s it. Then you would see the groups the user belongs to.
Here is an example running against a SharePoint connector that was designated as a group lookup:
<Group namespace=”Default”>NT AUTHORITY\authenticated users</Group>
<Group namespace=”Default”>NT AUTHORITY\interactive</Group>
<Group namespace=”Default”>MYCORP\quality center</Group>
<Group namespace=”Default”>MYCORP\it ad admin</Group>
<Group principal-type=”unqualified” namespace=”Default_myspserv”>[http://sharepoint.mycorp.com]IT Users</Group>
Groups from both Active Directory and SharePoint were retrieved for the user in question.
Here are a few interesting observations:
- This approach works for all the connectors provided by Google, and all the connectors built on top of Google connector framework 3.x.
- This approach also works for connectors that obtain user groups by connecting to content source system at runtime.
There is no need to specify user’s password in the request XML file. It will be very convenient for GSA admin to troubleshoot search issues for everyone.
The request content can include domain information so that you can verify the handling of domain during group lookup.
- This approach can also be used for readiness test of group lookup on connectors, especially for complicated connector implementation, such as Google SharePoint connector.
Recently I deployed a Perficient connector to a client. Even I was not granted access account to the system due to the client’s policy, with this approach I was still able to easily verify the user’s group membership and the controlled-access content a user was supposed to search.
Another good usage of this approach is monitoring the connection health to external database from Connector Manager, without even worrying about the connection string to the external database and the credential of database user account.