[midPoint] New ldap connector and auxiliary objectClasses

[midpoint at mybtinternet.com]

Hi Radovan,

  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

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

  However, thx for adding the support.

Regards,
  Anton


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

Hi,

On 10/22/2015 04:19 PM, midpoint at mybtinternet.com wrote:
>   A number of directories, including OpenDJ, IBM, etc, support schema 
> definition using a unique string instead
>   of OID (dotted notation). This makes the process easier, less prone 
> to error, and you don't have to track
>   OID numbers actively.

Yes. It is also violation of LDAP stadard as far as I'm aware. But I 
know very well that this is common practice. The problem was that as 
this is a violation of LDAP standard then the Apache Directory API 
(which we use for LDAP access) haven't supported it. I have fixed the 
Apache Directory API to tolerate non-numeric OIDs. But that happened 
after the midPoint 3.2 release. And actually the Apache Directory API 
with that fix was release just this week. Therefore the LDAP connector 
in midPoint 3.2 does not support it yet. The most recent development 
version of the connector does support it. If you are interested you can 
build that connector yourself from the source code:
https://github.com/Evolveum/connector-ldap
Or you can use development snapshot from our nexus:
http://nexus.evolveum.com/nexus/service/local/repositories/snapshots/content/com/evolveum/polygon/connector-ldap/1.4.2.0-SNAPSHOT/connector-ldap-1.4.2.0-20151020.202328-48.jar

>   In 3.1.1 with the old connector the first definition worked and I 
> have used this syntax for several years;
>   hope we do not have to regress ...

LDAP connector in midpoint 3.1.1 was a totally different connector. The 
connector in midPoint 3.1.1 was a based on Sun JNDI and it was quite 
antiquated. Use of JDNI is also a development dead end. MidPoitn 3.2 has 
a completely new generation of LDAP connector. It is explained here: 
https://wiki.evolveum.com/display/midPoint/LDAP+Connector+Migration

The problem with this regression was, that we were testing midPoint with 
LDAP servers that are LDAP-compliant. Since the release of 3.2 we have 
also added some non-compliant servers to the testing suites. But still, 
the amount of weirdness that some LDAP servers (and schema extensions) 
can provide can still come with a surprise. So I really appreciate any 
reports of issues with the new LDAP connector.

-- 
Radovan Semancik
Software Architect
evolveum.com

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