How GSA does Authentication with Multiple Repositories

Summary

This page describes the behavior of the GSA when content from multiple repositories were indexed and security is required, and how authorization is handled by an LDAP Proxy server.

Pre-requisites

The GSA must be configured to authenticate/authorize with LDAP and to use per URL policy ACLs. This in order to make early binding possible.

Context

A user does a search in the GSA. At this moment, the GSA will authenticate the user against the configured LDAP server, and then send an LDAP request for groups to which the user is member of (in order to get authorization done).

LDAP proxy server

The configured LDAP server on the GSA, in this case, is a custom implementation of ApacheDS done by Search Technologies. This LDAP server, will act as a proxy between the GSA, and the costumer real LDAP server.

Additionally, this ApacheDS implementation will detect user group requests, and send them to an Aspire pipeline so that information from different repositories is included as well in the response sent back to the GSA.

With this approach, early binding is possible with content from different repositories (some GSA connectors, only support late binding, which is much slower) and also, permits to handle nested groups (from Active Directory and SharePoint for example).

For example, assume content from SharePoint and the File System was indexed into the GSA (ACLs included in documents). If authorization is required, ApacheDS will take the user groups request sent by the GSA, extract information from it, get groups from the costumer's real LDAP server, and finally get groups from SharePoint. So, the final response sent back to the GSA, will not only include groups that will allow authorize File System content, but also SharePoint content (with early binding).

Group request sent by the GSA

The LDAP request for getting user groups contains the following filter:

(|(uniquemember=%dn)(uid=%s))

 

For example:

(|(uniquemember=CN=Administrator,CN=Users,DC=contoso,DC=com)(uid=administrator))

 

This filter is required by ApacheDS, so that it will be able detect it as an user groups request. Thus, sending the request to an Aspire pipeline in order to get group membership information from all repositories. Part of the configuration done to the GSA to work with ApacheDS, is to set up this filter.

The selection of that particular filter, was because those attributes were supported by ApacheDS LDAP schema by default, while other attributes from Active Directory like “member” are not.

Once the request was analyzed and sent to a pipeline, stages will use the user DN and user UID (samAccountName) from the filter to get group information. Those stages, will know specifically how to get that information from different repositories. So far, this ones exist:

LDAP (using Java JDK).Active Directory (using PowerShell).Active Directory (using C++ and .Net Framework -> under construction).SharePoint (using web services).Documentum (using EMC API).

The LDAP and Active Directory stages must use a different filter to get user groups than the configured for ApacheDS.

By default, this one is used:

(|(member=%dn)(member=%uid))

 

For example:

(|(member=CN=Administrator,CN=Users,DC=contoso,DC=com)(member=administrator))

 

 

Name Mangling for GSA

Index a document:
  -  It has ACLs for two different domains:

        DX\worker1 --> indexed as --> DX@worker1
	DX\workers --> indexed as --> DX@workers
	DY\managers --> indexed as --> DY@managers
	DY\workers --> indexed as --> DY@workers


** User logs into GSA: **
  -  Logs in as DX\worker1

  -  GSA Calls LDAP (Aspire LDAP)

  	.  Aspire LDAP sends DX\worker1 to Customer's LDAP
	.  DX\worker is authenticated

  -  GSA Calls LDAP and asks for Group Expansion of DX\worker1

	.  Aspire receives group expansion request
	.  Aspire expands all of the groups
	.  Aspire returns:
		DX\worker1 -> DX@worker1 DX@workers

  -  GSA does the search
	.  Filter created:  (worker1 OR DX@workers)
  • No labels