Background: The LDAP (Lightweight Directory Access Protocol) protocol is used for uniform access to the directories, such as OpenLDAP, MS Active Directory Service, etc. Directory, as against many other databases supported, has hierarchical structure of data storage (i.e. it is not a relational databases) and has the language of inquiries distinguished from SQL. Let’s connect transparently two worlds: hierarchical databases (LDAP) and relational databases (using SQL language).
Rationales:
1. A lot of DB clients were designed for RDBMS access only. SQL instructions are sent by the client and they are deeply implemented in the code. It will be fine if the user will have an opportunity to work with LDAP using all already-implemented features and using LDAP servers transparently (neglecting the hierarchical essence, language used, and storing mode but consider that works with a standard RDBMS);
2. But LDAP, as against other wide-supported databases, has hierarchical structure of data storage and has the queries language distinguished from SQL or any other based on relational calculus;
3. It involves a few tasks that are needed to be defined, resolved and implemented: SQL definitions (relations and constraints) to LDAP mapping, SQL to LDAP data types mapping, SQL language to LDAP API mapping. Some kinds of “front-end conversion” tool have to be developed in order to perform these tasks;
4. On the other hand, it is a common situation when it is needed to use the relational databases as de-facto storage for LDAP. The common solution is an integrating of an back-end solution, which will catch LDAP-calls and redirect to an relational database. Some kinds of “back-end conversion” library have to be developed in order to perform an easy, power and flexible mapping of information about required LDAP attributes, filters and Base DN to the SQL statements.
This document is a specification over these tasks.
The main idea: A front-end will be situated between user and LDAP server and will “translate” SQL:1999 queries in native LDAP C API calls. The task can be split into 3 distinct subtasks:
1. To represent logically LDAP data sources as usual RDBMS (mapping). The mapping is based on a LDAP notion of “objectClass” which means a class of any LDAP “entry” (MS Active Directory use "objectCategory" instead). Each LDAP “entry” will be a row in relation with corresponding “objectClass” name. Standard LDAP “dn” field which means DN (Distinguished Name - full global unique LDAP “entry” path) will be used as GUID and provides data access without loss of hierarchical features;
2. To translate SQL:1999 queries into a corresponding set of LDAP C API calls with the most possible restrictive filters (but with no loss of data);
3. To receive the data from the server and provide an additional client-side processing and checking in order to conform to SQL:1999 standard.
On the other hand, a library will be developed for mapping different pieces of information about standard LDAP filters, list of inquired LDAP schema attributes and used LDAP Base DN and user-customizable mapping rules into correspondent pieces of SQL statement.
Related downloads (use AS IS at your responsibility):
SQL2LDAP Specification full analysis document
SQL2LDAP implementation (C++ on Linux and VC++)
Also the next enhanced version for gcc 3 and Visual C++.Net is available at request.