RE: Further development of chain overlay?

["Pierangelo Masarati" <ando@sys-net.it>]

>>
>> 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 see your point; in this case, a good idea could be to provide
a set of acceptable URIs, with administrative user to provide
authorization proxying.  Non-trusted referrals could be chased
anonymously

>
>> 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.

What's happening, apparently, is that the session is opened anonymously.
I'll look at it a bit more.

Another issue I noted, by playing with this stuff, is that when back-ldap
is used to proxy a server that contains referrals, they are returned as
serach references AND chased.  Maybe we should make referral chasing
optional, and, if selected, simply drop the search references.

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it