Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

It is completely the responsibility of the core-jndi module to handle the expected modes and behavior for JNDI LDAP providers while dealing with referrals. Likewise the protocol-ldap module is responsible for complying with LDAP specification requirements concerning the handling of referral entries with and without the presence of the ManageDSAiT Control.

Note

This will be changed back to what we had before. Handling referrals at the protocol level is a real burden, as we have to do a second request (a lookup) to check that the manipulated entry is a referral or not. As it's very unlikely that entries are referrals, this might add an extra time to do the operations, when it's not necessary.

Adding a cache to avoid this double lookup helps, obviously, but it can't be done efficiently into the protocol part, as we have to store normalized values of the cached elements, which is done in the Normalizer interceptor. Plus adding the fact that we can't deal with access control at the protocol level forbid the usage of a cache storing entries.

For these reasons, I do think that handling referrals in an interceptor is the good way to doWe will restore a ReferralInterceptor for another reason: to avoid a performance penalty we have when doing a lookup to determinate if an entry has a referral ancestor. This interceptor will manage the Reefrral cache when adding/deleting or modifying a referral.

Motivation for Changes

The big bang effort to refactor JNDI constructs out of the server achieved many of it's intended goals. JNDI was complicating the picture and often causing an impedance mismatch if not complete confusion on how to bridge between JNDI and the protocol. There was too much complexity as a result.

...

Property Setting

Description

ignore

Ignore referrals (they are considered as normal entries)

follow

Automatically follow any referrals

throw

Throw a ReferralException(in the API reference documentation) for each referral

...

Section
Column
width70%

Here's a slightly modified example DIT used in RFC 3296. We'll also use this to elaborate on the behavior of operations based on the different scenarios outlined in 3296.

Info
titleLegend

Green nodes are actual entries. Red nodes are referrals.

Finding target in non-search operations

The handling for add, compare, delete, modify and modify DN operations to the target entry operated on is the same. The RFC gets a bit confusing when describing different scenarios and it's examples are lacking. They could have picked referrals where the DN is not the same as the reference to better demonstrate what they exactly meant. Regardless there seems to be 4 3 cases worth considering (wether the added entry is a referral or not is irrelevant) :

  1. target is present, and has no ancestor which is a referral
  2. target is present, and has an ancestor which is a referral
  3. target is not present, and no ancestor is a referral
  4. target is not present, but an ancestor is a referral
We have to combine those 4 cases with the fact that the ManageDSAIT control is used or not.

(whether the added entry is a referral or not is irrelevant) :

  1. target is present, and has no ancestor which is a referral
  2. target is not present, and no ancestor is a referral
  3. target is not present, but an ancestor is a referral

(the special case "target is present, and has an ancestor which is a referral" is impossible...).

If we consider the tree we are using for our samples, those 3 cases can be represented as :

  1. target's DN is "o=MNN,c=WW" or "ou=people, o=MNN, c=WW" (in this last example, the associated entry will be a referral.
  2. target's DN is "o=absent,c=WW"
  3. target's DN is "cn=Alex karasulu,ou=people,o=MNN,c=WW"
Column
width30%

Code Block
titleOU=People,O=MNN,C=WW
ou: People
ref: ldap://hostb/OU=People,DC=example,DC=com
ref: ldap://hostc/OU=People,O=MNN,C=WW
objectClass: referral
objectClass: extensibleObject
Code Block
titleOU=Roles,O=MNN,C=WW
ou: Roles
ref: ldap://hostd/ou=Roles,dc=apache,dc=org
objectClass: referral
objectClass: extensibleObject

...