LDAP Will Fail
First there was e-mail. Then web browsers. According to the folks who ought to know, a unified directory service is going to be networking's next Killer App. I am somewhat inclined to agree, although I don't think it's going to succeed for at least five years, unless the industry really gets its collective act together pronto.
Although lots of progress has been made (most notably, the formal publishing of the LDAP v3 protocol spec), this is nowhere near the level of directory service that will be required in order for the technology to become pervasive. As we all know, the only technologies that truly succeed are those that become commodities. Unfortunately, we're miles away from commodity-class directory access.
For example, LDAP is currently useful as a lightweight e-mail lookup service. Using Netscape Communicator or Microsoft Outlook, you can easily query an LDAP server to locate the e-mail address of another user. But this is nothing compared to where directories must be in the future in order for them to become truly pervasive, commodity-class tools along the lines of SMTP and HTTP.
There are some interesting uses of LDAP in the works now. CCOM Information Systems is providing LDAP interfaces into PBX and CTI systems, allowing caller ID integration by way of LDAP lookups. FedEx also has an LDAP interface to their package delivery service, allowing you to query their server for package tracking information. Even hardware vendors are getting into the act, looking to provide LDAP interfaces for everything from access switches to firewalls.
LDAP is Too Weak and Too Inflexible
These are interesting alright, but just a few examples. In order for LDAP (and directory services in general) to succeed however, we need a million such examples, rather than a handful. The most powerful thing about LDAP today is that it offers just this possibility. Unlike the proprietary nature of Novell's NDS, Sun's NIS+ and Banyan's Vines, LDAP provides a vendor-independent directory access mechanism. Developers don't have to write to all of the proprietary services, but instead can write to a single open service.
Just as mail-enabled applications began to blossom once the SMTP standard was leveraged, the number and variety of directory-enabled applications will also explode as vendors start leveraging LDAP as a universal directory service API and transport.
What's required to make this happen? Well, several things, although primarily, LDAP just needs to grow up and take on some of the broader functions that its proprietary cousins have offered for a long time. Currently, LDAP does not offer the depth or breadth of the services available with NDS or Vines. There are no decent user authentication services for example, nor access control mechanisms, nor management tools, etc. And until these advanced services are available, LDAP will not live up to its promise.
What's Needed?
Over the next few weeks we'll be exploring some of these issues in more detail, but for now, here's a summary of what will be needed in order for LDAP to succeed as a commodity technology:
- Put LDAP interfaces on everything, and I mean everything. If it can be configured, that configuration information ought to be accessible via LDAP. Every telnet, e-mail, and database client should allow their configuration settings to be stored in and retrieved from LDAP databases. Every web page ought to to be stored in LDAP. Ad nauseum. Conversely, anything capable of acting as a repository needs to also be LDAP enabled, allowing new data to be stored in, and legacy data to be retrieved from the database using LDAP queries. This is a lot of work, I know, but there are ways to do it in manageable chunks.
- We need a better way of retrieving information. The X.500 syntax currently in use is one of the most hostile and rigid query structures I've ever seen. These are the same reasons that X.500 didn't succeed on its own. The syntax and structure just plain sucks. Let's find something - anything - better. And while we're at it, let's find a way to declare and standardize new datatypes, allowing us to return object attributes in a manner that is immediately recognizable to all those newly-enabled LDAP clients from step 1 above. We can certainly use MIME for part of this, allowing us to leverage existing client datatypes, although more will be needed (like telling a client which print queues are available and how to access them).
- We also need user-centric interfaces to that data. Computers don't use applications; people use applications. Different people have different preferences, different levels of access, and different views of similar data. In order for LDAP to succeed on a grand scale, we need to address the issues of end-user authentication and access control in a scalable and seamless manner. X.509 certificates don't cut it for a number of reasons. Kerberos works, although it has its problems, too. Until this issue gets resolved, directory services just won't reach mass market status.
- We need better management tools, especially for network services. One of the areas in which all directory services have fallen down is the lack of third-party management tools, preventing users like me from managing my network from a single, unified console. Again, LDAP's vendor-neutral nature uniquely positions it to solve this problem, assuming vendor conflicts don't prevent this from happening. Netscape is promising that their Mission Control technology will provide some relief in this area, but it will take a lot of work to get everybody (including Microsoft and Novell) to endorse it in a consistent manner.
There are other issues with LDAP as well, such as replication and internationalization, although these topics are also being dealt with. However, I fear that we're putting technology before usability, and are ignoring the essential components that make a directory service of value to the mainstream communities.
We do so at our own peril. If we truly want directory services to be the next killer app, and if we want LDAP to be the enabling technology behind the next wave of interoperability and convenience, we must address the core issues that prevent it from doing so.
Copyright © 2010-2017 Eric A. Hall.