Additional <filter> in referrals (Was: Help with a referral)

[masarati@aero.polimi.it]

>>
>> Referrals don't work like that.  Read RFC4511: the <attrs> field is not
>> mentioned.  It mentions, indeed, the <filter> field, but OpenLDAP does
>> not
>> handle this.  The behavior you possibly expect is not strictly
>> specified,
>> AFAIK.
>>
>> I think you have a couple of options:
>>
>> 1) use ACLs to hide that entry to some specific clients
>>
>> 2) use a dummy proxy instead of a referral; the dummy proxy could
>> massage
>> the request/response DNs, and the original server could use ACLs to hide
>> that entry from the results returned to the proxy.
>>
>
> I tought OpenLDAP could support that kind of referrals. Now I think
> the best option is the best for my scenario.

The <attrs> issue makes little sense.  The <filter> issue may be worth,
although clear semantics need to be defined.  I note that rfc 3296 appears
to explicitly prohibit a filter in the LDAP URL, while rfc 4511 instructs
the client about using the filter in the LDAP URL if present.  This is not
strictly a contradiction, because the server may modify the URL stored in
the Named Subordinate Reference object before returning it to the client,
e.g. by adding a filter.

For example, in order to obtain what I think you mean, a <filter> field in
the Named Subordinate Reference object's URL, e.g. "(!(uid=admin))", would
require the server, in case of a search with scope "subtree", base
"ou=Paople,dc=example,dc=com" and filter "(attr=val)", to return a
referral

ldap://host/ou=People,dc=example,dc=com??sub?(&(!(uid=admin))(attr=val))

The filter should be completely removed when performing other types of
operations, in compliance with rfc3296.

If you think this makes sense and you would like to see it implemented, I
suggest to file an ITS as a feature request, pending technical discussion
<http://www.openldap.org/its/>.

p.