Re: [Fwd: sUffixAlias]

[Pierangelo Masarati <pmasarati@bci.it>]

Howard Chu wrote:

> > -----Original Message-----
> > From: ando@core2.bci.it [mailto:ando@core2.bci.it]On Behalf Of
> > Pierangelo Masarati
>
> > To avoid excessive implementation overhead I'm thinking about
> > handling such
> > feature at the slapd level, i.e. right before sending any search
> > result, so
> > any backend
> > would allow it. I'm still trying to figure out how to handle
> > add/modify/delete
> > stuff.
> > All of this should be done only in case the masquerading is intentionally
> > switched
> > on, otherwise it is likely to add undesirable overhead.
>
> I think you misunderstood part of my meaning. In my implementation, the LDAP
> proxy performs all DN translation. It acts as an LDAP client of the target
> directory. The target directory does nothing special with any requests or
> responses. The proxy code collects responses and massages them, then relays
> them back to the ultimate caller. In our nested hierarchy, the client can
> also
> be another proxy from yet another level up the tree, and so on ad nauseum.

OK, what I mean is: you implemented it as part of the back-ldap, which already
is a proxy, i.e. something that acts as a server with regard to the caller,
and as a client to the callee. In my opinion, if the rewrite is done at the
slapd side,
i.e. in servers/slapd/{bind.c,search.c,add.c,...}, the dns can be massaged
regardless
of the backend stuff is coming from/going to. Of course, the back-ldap is
likely to
be the most suited to such massaging. Another application could be (correct me
if I'm wrong) a "flat" DS on a single backend, e.g. holding all the employees
of a
company, which can be accessed directly or by masquerading the suffix, to make
the employees of a branch look like they have their own branch DS and suffix:

# common base
dn: o=Big Company, c=IT

# branches
dn: ou=Branch 1, o=Big Company, c=IT
dn: ou=Branch 2, o=Big Company, c=IT

with

o=Pretty Branch, c=IT <==> ou=Branch 1, o=Big Company, c=IT
o=The Cool One, c=IT <==> ou=Branch 2, o=Big Company, c=IT

but still allowing common searches with the common base


>
> As such, there is no overhead imposed on regular backends that are contacted
> directly by arbitrary LDAP clients. The DN translation only occurs when
> someone contacts the proxy. Add/Modify/Delete is not much different from
> search, in all cases you must walk through all attributes of requests and
> responses to look for DNs to rewrite. Search is actually more complicated
> because we use a thread pool to spawn searches over multiple subordinate
> servers in parallel. All other requests are pretty simple since they only
> affect a single target. (Sometimes this restriction is annoying, but there
> are hacks around that too...)

This sounds very interesting.

>
> I was going to submit this back-ldap change to the main tree but we have
> some
> licensing decisions to resolve within Symas still. We consider this a still
> novel feature, with pending patent. I personally think it's useful enough
> that someone else will duplicate our work, and then we'll be stuck on the
> nonstandard side of the fence. sigh... Anyway, if you go ahead and write
> this code and submit it back to OpenLDAP, it will all be a moot point. Go
> for it...

I think I'll do, at least because we need something of the sort. First I'll try

the easy part, that is the slapd-side of the work.

Regards, Pierangelo


--
Pierangelo Masarati <ando@sys-net.it>
SysNet s.n.c.