[midPoint] New ldap connector and auxiliary objectClasses

[midpoint at mybtinternet.com]

Hi,

  I agree with your principals around retrieving and interpreting the schema. However,
  attribute names are not supposed to be case sensitive. I have worked with many
  servers, and have only encountered one that was. I believe this was configurable
  in that particular server.

  As for the server that provided no syntax definitions; wow!! I have not encountered
  that before ... do you mean when querying the server or no syntax period? It seems
  inconceivable how such a sever could be compliant enough to become *popular*.
  Some servers require special attributes to return certain types of information; e.g.
  operational attributes, parts of the schema, etc.

  Something else I have encountered is that several servers allow schema checking
  to the relaxed or turned off completely. I have also come across practises when
  support organizations disable schema checking when bulk loading data as this
  potentially saves a lots f time ... both bad practises. This can account for duplicate
  OIDs and illegal characters in attribute names. As a rule I avoid illegal characters
  and ones that may be interpreted by shells during scripting.

Regards,
  Anton


----Original message----
>From : radovan.semancik at evolveum.com
Date : 23/10/2015 - 12:04 (BST)
To : midpoint at lists.evolveum.com
Subject : Re: [midPoint] New ldap connector and auxiliary objectClasses

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

_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint