[midPoint] New ldap connector and auxiliary objectClasses

[Radovan Semancik]

Hi,

On 10/23/2015 10:44 AM, midpoint at mybtinternet.com wrote:
>    Actually, it is not a violation of the standard, see RFC 4520, section 3.4,
>    published in 2006. http://www.rfc-archive.org/getrfc.php?rfc=4520

Yes. That looks to be a valid comment. Although I do no claim to be an 
expert on LDAP standardization ... anyway. Connector supports this now.

>    More curious though, is why Apache Directory Studio deals with this properly;
>    does this imply they are not using their own directory API?

Honestly, I do no know. Studio is using the same API, but it seems to 
use it in a very tolerant way. E.g. it looks like studio is not really 
using the schema for the operations. It seems to just recognize whether 
the attribute is string-like or binary-like for LDAP operations. But 
obviously, the Studio has to be able to parse the schema with 
non-numeric OIDs because there is a schema browser. I'm not sure how 
that could work. Maybe the Studio is using a different method to work 
with the OIDs. I have chosen the methods that seemed to be the most 
correct way of working with schema (get object class definition, find 
attribute definitions, get syntax OID, find syntax definition, ...). 
Unlike the Studio, the connector has to be quite precise about data 
types (boolean, int, and later also timestamps) for midPoint to present, 
compare and validate the data correctly. I hoped that this method will 
properly utilize attribute types, address upcase/lowercase issues with 
attribute names, attribute aliases and so on. In retrospect, that might 
have been quite a naive assumption. Soon the problems appeared as we 
started testing the connector with commercial LDAP servers(*). So I'm 
gradually relaxing the code and I'm adding various fall-back code paths 
to work even with bad servers. I'm also contributing the code to Apache 
Directory project. But, I do not want to relax the code too much ... I 
think there is something to consider here: 
https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00

(*) I do not want to point fingers here ... but one popular commercial 
LDAP server does not provide syntax definitions at all. Other (not so 
popular) server has two attribute definitions with the same OID. Several 
servers use attribute names with illegal characters in them (like hash 
or space). And so on ...

-- 
Radovan Semancik
Software Architect
evolveum.com