Identity connectors are important part of any identity management (IDM) project. For an IDM solution the connector provide interface to the outer world. And there are few connectors that almost any IDM solution needs: LDAP, Active Directory and CSV. New versions of those connectors were released recently. And there is an interesting story behind those connectors.
Back in the ancient times of early identity management (2000s) every IDM system had proprietary connectors. This was a real pain. Connectors were difficult to develop, even more difficult to maintain and there was no code sharing to make the work easier. Then in late 2000s Sun Microsystems introduced Identity Connector Framework (ICF). Even though this framework still left much to be desired it was a great leap forward. The framework was released as free and open source software and that made all the difference. However, almost immediately there was a big problem. Sun was acquired by Oracle. And Oracle closed down ICF development. But the genie was already out of the bottle. Original ICF source code was picked up by several IDM product teams and it was significantly improved. And the result is a new connector framework called ConnId. This is something that is still quite a rare sight: a collaborative development of several competing organizations. ConnId is now much better than the original framework. This is the real power of open source.
But the connector framework is only one half of the story. The framework won’t work without the connectors. The original ICF framework came with a bunch of connectors. But those were – for the lack of a better word – terrible. There are few connectors that are used in IDM deployments all the time. Such as LDAP connector. The LDAP connector that came with ICF was based on a Java Naming and Directory Interface (JNDI). This is a notorious Java subsystem with an ambition to unify all directory systems that ever existed. Because JNDI is such a generic abstraction then it is inherently limited in its capabilities. But it is not all bad. It gets worse. JNDI is also difficult to use and it is not evolving much any more. The result is that ICF LDAP connector was quite bad. And even worse, it was a development dead end. It made no sense to improve the connector. And the situation was similar for Active Directory connector. The connector that was part of ICF was a .NET code that was using proprietary interface to get to Active Directory. As that .NET code was wired into the Java framework it created an immediate deployment and maintenance nightmare. And for the CSV connector: there was none. None at all.
There was just one reasonable way out of this mess: rewrite the connectors from scratch. So we did it. More than two years ago there was a first release of a brand new LDAP connector. Soon after that the connector was extended to support the “Microsoft dialect” of LDAP protocol and thus the LDAP-based Active Directory connector was born. Those are all perfectly native Java connectors. There is not a single bit of proprietary code. Therefore, there are no integration nightmares any more. Support for PowerShell was added to AD connector last year, so the connector can create home directories and set up the environment. There was also an ambition to control Exchange mailboxes with the connector. But for that there is a big obstacle. It is known as “second hop problem” and administrators working on Microsoft platforms are frequently haunted by it. There was a solution to this problem in a form of CredSSP protocol. This is a really convoluted and nightmarish protocol and there was no usable implementation of that protocol in Java. So we implemented it. The AD connector can control Exchange mailboxes now. This is a process of continuous improvement. That’s how we like it.
The current midPoint LDAP connector is perhaps the best LDAP-based identity connector available. It has full schema support and it supports all the common LDAP controls. It was tested with a wide variety of LDAP servers from the common ones to exotic ones (including one X.500 server). Active directory connector was adapted to Microsoft LDAP quirks and it works with all common Active Directory versions. There is also support for Active Directory forest topologies. But there is more than just LDAP. We have also rewritten the CSV connector from scratch. We had a first version that was more-or-less just a prototype and it has outlived its usefulness some time ago. Therefore, now there is a new and improved version of the CSV connector. Perhaps the only connector that still waits for rewrite is a database table connector. We would love to do that and we are looking for the funding. Anyone interested in sponsoring the rewrite is more than welcome. But even for the SQL-based connectors there is now an connector supertype project. This allows rapid development and sustainable maintenance of custom SQL-based connectors. Those are really next-generation connectors that are miles apart from the obsolete connectors of early 2000s. The technology has moved on. We have pushed it forward a bit. That’s what we do.
Rewrite of the connectors was no easy feat. Huge amount of time was spent on development, testing and maintenance. But it was all worth it. Every second of it. Rewrite of the connectors was one of the best decisions that we have ever made. It pays off to get rid of the dead weight so one can move faster. Too bad that many IDM solutions are stuck in antiquated technology. But not midPoint. MidPoint is indeed a second-generation IDM system.