Skip to content.
|Networking government in New Zealand.
 

2 Specific Questions:

2.1 OpenLDAP - Background

2.1.1 It has been indicated in previous contact with members of the E-Government unit that an Open Source Directory capability may be worth investigating as an alternative to pre-maturely selecting any particular Directory vendor. Such an option would allow some experience to be gained in the implementation and usage of a Directory for minimal outlay.

2.1.2 The clear leader in the Open Source Directory space is OpenLDAP (http://www.openldap.org/). It has become the standard in its category.

2.1.3 Mid-2001 we decided to investigate OpenLDAP to assess its strengths and weaknesses. We installed OpenLDAP onto a Red Hat 7.1 Server instance, carried out basic configuration and set about extending and testing it. For testing purposes, a variety of e.mail clients, address books and LDAP-specific tools were used to test connectivity and to verify extensions and updated data content.

2.1.4 The first task undertaken was to extend the schema with an interpretation of the proposed S.E.E. Directory. After a few simple teething problems (very strict formatting expectations) the schema was up loaded without difficulty. Conclusion: easily extendable.

2.1.5 The one caveat though is that the Directory needs to be shut down and then restarted for it to pick up the new schema. This is consistent with the highly read-optimised architecture of LDAP and can be accommodated with a small amount of forward planning. Updating the schema is, after all, not a common occurrence. A network of multiple replicated directories would require that the 'Master' be updated first, then each of the replicas in succession. This is standard practice and not unexpected.

2.1.6 The second task was to load some test data into the Directory using the newly extended schema. Making use of some readily available LDAP tools, it was simply a matter of converting the sample data into the required format and then bulk loading it into the Directory. Conclusion: quick, efficient and easy.

2.1.7 Only several hundred entries were loaded and no testing was done beyond that. Although no specific problems are expected, the data capacity limits of OpenLDAP should be tested at some point. For completeness, this should be carried out particularly in relation to LDAP read performance, preferably on various hardware platforms.

2.1.8 The next two areas investigated were the built in access controls (security) and the replication capabilities (Master / Slave) of OpenLDAP. Whilst not specifically tested, every indication was given that both these areas would perform in line with expectations and as documented. Prior to adoption as a serious LDAP platform, however, both these areas would need to be thoroughly tested. Conclusion: promising, but testing required.

2.1.9 On the whole, we were very impressed with the stability, consistency and reliability of the product. In addition, its general conformance to LDAP standards appeared to be exemplary.

2.1.10 Overall conclusion: very promising, definitely worth investigating.

2.2 MetaDirectory Type Tools

2.2.1 A MetaDirectory is a product that synchronises a central LDAP Directory with the internal directories or address books of other applications or systems. This is normally accomplished by a set of 'connectors,' where each connector targets a particular protocol or product.

2.2.2 Connectors work in one of three ways:

  • At the lowest level by passing file information back and forth using scripts and command line utilities to synchronise the data;

  • At the highest level by adopting a common interface protocol, eg XML or LDAP.

  • In between the two using various combinations of specialised executable modules residing 'inside' the MetaDirectory, the targeted product or both.

2.2.3 All MetaDirectory products work using one or more of the above methods.

2.2.4 The question has arisen as to the availability of free or low cost MetaDirectory type tools in the Open Source community or similar. In particular, the existence of ODBC to LDAP connector tools was considered potentially useful. To our knowledge none exist. We did however find traces that others were also looking for similar products.

2.2.5 It would appear that while LDAP directories are considered a commodity product, and unlike ODBC where numerous options exist, LDAP connectors are still considered 'valuable' and thus are so far only available as part of commercial MetaDirectory offerings. This is expected to change, but probably not within the next 12-18 months.

2.2.6 This situation however does not mean that no alternatives exist. As all MetaDirectory products have the ability to carry out file-based synchronisation using some form of scripting language, such as TCL or PERL, there is nothing to stop a programmer writing say a ODBC to LDAP connector in a similar fashion. The maintenance of the resulting code however would need to be agreed, a situation that would be no different with any MetaDirectory product / vendor solution as each implementation is customised to some degree.

2.2.7 The question then arises as to the ability of the OpenLDAP Directory product to function in a MetaDirectory capacity. By itself OpenLDAP is a well executed, fully standards compliant LDAP directory. The basis for any MetaDirectory solution requires at the least just such a component as noted above (2.2.1). OpenLDAP thus provides a very solid candidate for a MetaDirectory solution but is not in and of itself a MetaDirectory product. With some effort, however, a MetaDirectory capability can be built up around OpenLDAP by the creation of 'connectors' to fulfil data synchronisation requirements.

2.2.8 Any approach based on the use of OpenLDAP does not in any way preclude the downstream adoption of a vendor-specific LDAP and / or MetaDirectory solution. All MetaDirectory products are capable of synchronising with a generic LDAP Directory, which of course includes OpenLDAP, just as the data can be extracted from any LDAP Directory to populate any other LDAP Directory. Thus the adoption of OpenLDAP as an interim explorative solution in fact lays an important foundation for growth and future upgrade possibilities of a S.E.E. Directory.

2.2.9 Overall conclusion: a viable basis for MetaDirectory capabilities and a solid foundation for future upgrade options.

2.3 Potential Limitations Affecting LDAP Implementations

2.3.1 We were asked to consider potential limitations affecting LDAP implementations. The key issues we considered were:

  • Security

  • Certificate handling

  • Access controls

  • Integrity

  • Extensions

2.3.2 Firstly, Security. There are two issues here: (1) security of the data on the server; (2) security of network based interactions with that data.

2.3.3 The former is amenable to normal server type controls. For example, restricted physical access to the server, careful management of backup data and ensuring currency of the latest OS security update patches. It is all about good server management and house keeping practices. Nothing new on this front and in fact it has little to do with LDAP per se.

2.3.4 The latter is where concern is not so much with normal anonymous access to read only data, but to control access to more secure or privileged data. A secure channel between a client and the server prevents interception and data substitution. Again this is not particular to LDAP, but is a general issue of securely managing and protecting server based applications and their transaction traffic across open networks.

2.3.5 What has emerged as a common practice is the use of SASL, SSL, and Kerberos as means of maintaining data integrity and security across the network. Here, integrity is about ensuring that the data has not been tampered with and security is about ensuring that it can't be read in transit. As a side note, OpenLDAP supports the above three security protocols.

2.3.6 Secondly, Certificate Handling. This issue concerns the tension between a CA's (Certificate Authority) use of attributes and the use of those same attributes in typical schemas. There are three base types of certificates: signature, authentication and encryption. So how does or should any one implementation of a directory cope with those different types of certificates in the face of the varying practices of CA's?

2.3.7 The emerging common practice to assist on this front is to choose to not explicitly store everything in the Directory. There is increasing use of the CA as the final arbiter for both holding and supplying certificates. In other words, it's allowing the CA to solve the problem and the Directory design merely makes implicit or explicit use of this. Put another way, on receipt of a certificate request, the Directory redirects the query to the CA's Directory or alternatively, incorporates the CA's Directory into its own 'tree' structure, and so transparently services the request.

2.3.8 LDAP version 3 explicitly supports X.509 certificates and binary objects in known fashions. However, there is as yet no agreed standard for the use and semantics associated with the most contentious of attributes in a certificate. Namely: O, OU and CN. A follow-on problem here is the fact that X.509 has specified the 'DN' of a typical certificate. So should that design decision dominate in the subsequent design of a Directory's tree and impose its own structure onto 'your' data, or should the problem be resolved in a different fashion. The trend seems to be towards solving the problem in another way, as noted in 2.3.8 above.

2.3.9 Thirdly, Access Controls. At issue here is:

  • the granularity of controls that are offered, eg. everything, specific objects, specific attributes through to more powerful query based filters for controlling access;

  • whether or not one can search across or even be aware of content that is in theory not allowed to be viewed; and

  • finally the net effect on performance these controls have.

2.3.10 Over the last 18 months there has been little or no change in these areas.

2.3.11 OpenLDAP offers what appears to be both fine levels of granularity and powerful query based filters for controlling access. What has not been explored is the impact this has on performance and the degree to which the various control mechanisms actually work. The lack of bug reports relating to these concerns would lead us to conclude that they basically work as documented. Testing will confirm this.

2.3.12 Access control is regarded as an internal matter by Directory products. Hence there is no standardised way of specifying the levels of access in such a way that can be used by different Directory servers. Some products use an explicit configuration file to define access controls. OpenLDAP is in this category. Other products provide a user interface for applying access controls to directory objects - but don't allow this information to be extracted and either re-applied (say as part of a recovery strategy) or transferred to another Directory server.

2.3.13 Fourthly, Integrity. This issue is to do with the structural integrity of the relationships between data objects within the Directory and to a lesser extent the value integrity of the data itself. Unlike current DBMS products where there are significant capabilities to define business rules governing both relational integrity across tables as well as value integrity of data content, no such generic capability exists for LDAP Directories. This situation has not substantially changed over the last 18 months or so and is unlikely to do so.

2.3.14 The one area where some level of integrity checking is possible is by making use of queries that for example explicitly look for either compliance with or non-compliance with specific rules. This requires Directories with powerful open searching capabilities, OpenLDAP appears to be in this category.

2.3.15 Finally, Extensibility. There was a tendency for directory products to continue to enhance their capabilities. The incorporation of business rules and interfaces to allow interactions with other systems being two examples. Such capabilities are now more associated with MetaDirectory products and ancillary tool sets. That said, OpenLDAP has a well-defined API that allows for programmatic extension of its request processing.

2.3.16 Conclusion: By minimising the use of non-standards based extensions and clearly demarcating directory versus non-directory functionality, none of the above issues have inhibited widespread adoption of LDAP directories.

2.4 Master / Slave Replication Capabilities

2.4.1 'Out of the Box' OpenLDAP has a Master / Slave replication capability. It is able to be configured in such a way that one instance of the Directory takes on the role of being the 'Master' and all other instances become 'slaves' of it.

2.4.2 This is managed via configuration files for each instance. When configured as a master, an instance keeps track of all changes since the last successful update of the slave instances. Then, either on a time basis, or based on the number of outstanding changes, the master contacts each slave in turn and sends an update. The update is in the Lightweight Directory Interchange Format (LDIF) - a standards based text form of directory data. Slave instances never accept updates except from their configured master. Thus a single tier hierarchy is established with the master at the top receiving and propagating all changes.

2.4.3 We have not tested this capability, but it is well documented and uses a simple and robust approach. Master Slave replication is used by at least one other major directory vendor.

2.4.4 Conclusion: a viable standards-based approach, not tested but promising.

2.5 Web Gateway Options (PKI & Directory Management)

2.5.1 A web-gateway to an LDAP Directory allows in the first instance searching ability of the Directory via any web browser. Secondly, in some cases a web gateway will also allow the ability to edit directory content, and potentially allow for the creation and deletion of entries as well, whether that be general content or certificates.

2.5.2 Searching is for the most part done by anonymous access and usually only that part of the Directory visible to all can be searched. Searching of protected entries as well as the ability to edit, create and delete content requires an additional authentication step to ensure that the user is authorised to carry out the desired act.

2.5.3 A good web gateway, together with careful secure layering of information in a Directory, can therefore go a long way towards providing an effective remote administration capability. This greatly assists in assuring a high quality of data as people who are close to the source of information change, can be specifically empowered to keep that data current.

2.5.4 All Directory vendors bundle a web gateway with their Directory product. As each Directory has proprietary elements, this ensures that any specific needs of the product are met appropriately.

2.5.5 Some of these vendor LDAP web gateways appear to be capable of connecting to any standards compliant LDAP Directory. Whether a vendor would be willing to separate off their 'enhanced' gateway from their proprietary Directory product, however, is another matter. Indications seem to be that vendor web gateways are part of an unbreakable bundle. Or alternatively, that they may be purchased possibly for a cost equivalent to the Directory product itself (with perhaps their Directory included 'free' in the bundle).

2.5.6 There is only one Open Source effort to build a Web gateway that appears to have gained any level of support and adoption. That is Web2LDAP (http://www.web2ldap.de/).

2.5.7 There have been other attempts, but they don't seem to have been followed through. Source Forge (http://www.sourceforge.org/), for example, notes several attempts over the last five years or so, but none progressed from the lodgement of the initial idea. Another, Web500gw (http://www-user.tu-chemnitz.de/~fri/web500gw/home.html), has ceased further development as at 1998 after supporting LDAP version 1. LDAP version 3 is the current standard.

2.5.8 As for Web2LDAP, whilst appearing to offer good potential capability, it proved to be problematic to implement. We failed to get it working beyond the initial start page and were unable to actually connect to our OpenLDAP server to search or edit content. We admit that concerted effort could have been applied with a reasonably high chance of success. We chose however to not put in the effort as we assessed that the way the product had been assembled, together with a large amount of interconnected dependencies, resulted in a product that we couldn't recommend for use even on a trial basis in a government context.

2.5.9 The two remaining options in the web gateway sphere are: very simple searching interfaces built using tools such as PERL and adopting some form of middle-ware product, such as an application server, which exploits for example Java (JNDI). We are investigating both these options at the moment, as each would appear to offer some benefit in different contexts.

2.5.10 Conclusion: a web gateway is an essential component in providing a 'White Pages' capability and remote administration functionality.


[ Previous | Next ]