RE: back-ldap: proxying legacy apps to legacy or V3 servers

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Pierangelo
> Masarati

> "Randall S. Winchester" wrote:
> > Is there not some library routine that the current slapd uses when a
> > LDAP-V2 client connects to it?

There is not. Currently there are only a few effects in slapd with LDAPv2:
  a) bind is required before any other request
  b) server controls are not allowed
  c) extended requests are not allowed
  d) moddn is only modrdn, i.e., does not allow newSuperior
  e) results associated with referrals are different

There may be more differences, but you get the idea... There is no code that
addresses the character set differences.

> > I would think it acceptable for the proxy to only support ;

> > 1) LDAP-V2 client <-- LDAP-V2 server
> > 2) LDAP-V3 client <-- LDAP-V3 server
> > 3) LDAP-V2 client <-- LDAP-V3 server supporting LDAP-V2 clients

> > and not support

> > 4) LDAP-V3 client <-- LDAP-V2 server

> > Then the only conversion would be for "3)" which I would think is already
> > supported somehow?

I'm not sure I understand what the directionality of those arrows means...
I think Ando covered things pretty well here.

> As Howard said, it is not; only option 2) is truly supported (to the
> extent
> OpenLDAP client library and server implement LDAPv3); all the other
> combinations (of course option 4) is not) are supported as soon as the
> attribute
> values stick with the common part of T61 UTF-8 (plain ascii or so, I
> guess).
> The fact the current implementation also speaks LDAPv2 is a matter of
> protocol
> (i.e., I assume, supported/understood ber tags) which has little to do
> with
> the values that are transported.  The latter are always UTF-8,
> regardless
> of the requested/agreed protocol version (or, at least, that's how I
> understand
> it; someone else perhaps may better clarify this point).

I think the released code will be perfectly happy with both case 1 and case 2
above, because it really doesn't do any validation of text. If you use 8-bit
characters anywhere in your databases, config files (ACLs), etc., they will be
used as-is. This is fine for LDAPv2 clients and violates the LDAPv3 spec, but
you're guaranteed that the bytes going in one side come out the other side
exactly the same. If you add some config items to explicitly set the protocol
version to use with the remote server, it should all work fine. (Given that you
understand and accept the character set incompatibility.)

The development code is pure UTF-8. All input is checked for compliance and
illegal character encodings are rejected. So the proxy's ability to talk to an
LDAPv2 client or server is going to be restricted to purely 7-bit text, unless
someone goes to the trouble of writing some translation functions. (All of the
slapd internals will be expecting UTF-8 normalized DNs. This is a critical
problem if you want to configure ACLs on the proxy, but may not be much of an
issue otherwise.)

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