[Date Prev][Date Next]
Re: Fwd: LDAP backend
"Kurt D. Zeilenga" wrote:
> At 04:24 PM 2/4/01 +0100, Pierangelo Masarati wrote:
> >I was thinking about the possible problems your idea might discover.
> >In detail, how are you going to ensure the remapped
> >share the same, or a compatible, definition? What about attribute syntax?
That's a job for the person setting up the mappings.
> I note that this is a problem which exists in proxying even without
> mapping. That is, how does the proxy ensure that the attribute
> requested by the same as that returned by the server it is held
> in. One must be very careful to ensure 'foo' returned is same
> as 'foo' returned.
Well, I guess you're right; one could rely on the fact that "standard"
objectClasses/attributes comply with the standard on both sides, but
it would be nothing by a legitimate expectation. Otherwise the
LDAP backend could attempt a schema check at init time against
the schema published by the target host (in case it is LDAPv3
compliant and schema is made public), but this requires the target
server to be on at init time, and a schema update would be missed.
On the other hand, I wonder how heavy a per-operation schema
check, although restricted to the data that is being returned, could be.
It is apparent that it is the proxy admin is responsible for ensuring
a good correlation with the target host schema definition. In view
of this, the remapping feature could be of help in "extreme" situations.
The main reason for doing this remapping is to get schema compliance
with the local slapd's schema, although it might be at the expense of
some information. This is a choice that is made by the person in
charge of the local slapd, and we are just giving them the tools.
I think ideally the local slapd would download the schema of the
target LDAP server and use that for checking the particular
backend/suffix. This would require two things: per-backend schemas
and dynamic schema updates. These are certainly possible, but are
larger projects than remapping.