Whenever the Directory Proxy Server forwards a request to the backend set containing the user's entry, it forwards the request with an authorization identity that reflects the user's actual identity, since servers in that set already know about that user. However, when forwarding a request to a backend set that does not contain the user's entry, the Directory Proxy Server uses an alternate authorization identity that reflects the generic user with the same set of rights as the actual user issuing the request. Alternate authorization identities allow for the proper evaluation of access control rules for users whose entries are not present within an entry-balanced dataset.

There are typically only a few different generic class of users from an access control perspective, which can be placed in a portion of the DIT that is not below the entry-balancing base DN and is replicated to all servers in the topology. For example, assume that you have three classes of users: full administrators, password administrators, and normal users. You could create the following entries in the topology and assign them the appropriate access rights:
  • uid=normal user,dc=example,dc=com
  • uid=server-admin,dc=example,dc=com
  • uid=password-admin,dc=example,dc=com

Returning to the example scenario, the client with uid=5000 binds to the Directory Proxy Server, which sends a BIND request to entry-balancing set-01. Next, the client sends a SEARCH request for uid=15000. The Directory Proxy Server determines that uid=15000 lives on entry-balancing set-02. Next, the Directory Proxy Server then determines that the client uid=5000 does not have an entry on entry-balancing set-02. The Directory Proxy Server uses an alternate authorization identity that reflects the generic user, uid=normal user, which has the same set of rights as the client uid=5000 who is issuing the request. The access control is accepted and the SEARCH request returns a response for uid=5000.

Whenever a user authenticates to the Directory Proxy Server, the server can keep track of which backend set holds that user's entry and determine whether an alternate authorization identity is required. The server can also determine which of these generic accounts best describes the rights that the user should have.

When an alternate authorization identity is invoked, you will see authzID='dn:uid=normal user,dc=example,dc=com' in the server log, indicating that the alternate authorization identity was used. For example, if the user.15000 is in a different backend set from user.5000, the log will show the following:
% bin/ldapsearch -D "uid=user.5000,ou=people,dc=example,dc=com" -w pasword \
  -b uid=user15000,ou=people,dc=example,dc=com "(objectclass=*)"

[18/Aug/2013:11:54:35 -0500] SEARCH REQUEST conn=153 op=1 msgID=2 
via="app='Directory-Proxy address='127.0.0.1'
authzID='dn:uid=normal user,dc=example,dcom' sessionID='conn=2' 
requestID='op=1'" base="uid=user.150000,ou=people,dc=example,dc=com"scope=2 
filter="(objectclass=*)" attrs="ALL"

[18/Aug/2013:11:54:35 -0500] SEARCH REQUEST conn=153 op=1 msgID=2 resultCode=0 etime=2.038 
entriesReturned=1 authzDN="uid=normal-user,dc=example,dc=com"