RE: Further development of chain overlay?

[<hyc@OpenLDAP.org>]

> -----Original Message-----
> From: Pierangelo Masarati [mailto:ando@sys-net.it]

> Howard,
>
> I have considered the possibility to make the chain overlay
> also follow referrals as they are returned by a database.
> This can be also useful for "dumb" clients that cannot chase
> referrals by themselves; moreover, I'm about to allow chasing
> of referrals with URI different from the underlying back-ldap
> database, as well as multiple referral.

I believe it is useful to handle multiple referrals and such, but I think a
requirement here is that the underlying back-ldap have some knowledge of the
destination. The chaining concept really applies to explicitly cooperating
DSAs. The assumption is that all the DSAs that will be referenced are all
associated in two ways:
  1) they are part of the same overall DIB
  2) they are all under the same administrative control

The approach here should be to allow multiple back-ldap destinations to be
configured and select the right one based on the referral URI. In particular,
you must be able to provide an admin DN and credentials for each destination
server, in order for a lot of the other things to work.

> I have a problem about how proxyAuthz control is propagated:
> apparently binds are propagated anonymously; then operations
> also occur anonymously, but if the original operation was
> authenticated, the referred server correctly refuses to allow
> non-authd proxyAuthz.  Clues?

I haven't really looked at how the proxyAuthz stuff is put together. But it
seems that what is supposed to happen is that the admin DN is used to open a
session, and that session should be used by any proxyAuthz'd requests.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support