This book will help you understand and use the most important directory services?those based on the leading industry standards?without having to read the many esoteric standards documents available on the Web. I am tempted to start the book with a motivating example from my experience to explain why directory services are so important and why you should read this book from cover to cover, but I will resist. There is no need to tell a story from my experience, because I can tell a story from your experience. Every single one of you has had experience with directory services, whether you know it or not.
Did you log in to a computer today? When the computer checked your password, it was probably using a directory service.
Do you use a personalized start page, such as Netscape Netcenter? If so, your preferences and login information were found in a directory service and used to customize your experience.
Have you ever looked up the email addresses of long-lost friends on the Internet, or located the telephone number of the woman in receiving who can track down your lost package? Both of these tasks are also common uses for directories.
However, you don?t need to learn how to type someone?s name into a search engine or enter your password. What you do need to learn, and what this book will teach you, is how to apply the standards that make directory services accessible over computer networks ranging from the Internet to your corporate intranet to business partners? extranets.
We won?t stop there. The most pressing issue in the area of directory services today is simply that there are so many of them. Every application written in the last 30 years seems to have come with its own proprietary directory. Operating systems also have directories. Most of these directories don?t care about each other or even acknowledge the others? existence. This book will help you get these existing directories to work well with new, important standards-based directory services.
Finally, what good is a data repository without useful applications? If you are an application developer trying to get your existing applications to work with Lightweight Directory Access Protocol (LDAP), Directory Services Markup Language (DSML), and other directory standards, this book not only will help you get a handle on important application program interfaces (APIs), but also will deliver an understanding of the best strategies for using these applications to derive important application benefits.
Many of the people picking up this book may know my reputation as a long-time developer in the directory space. My background in this area includes writing the first comprehensive Perl module for accessing directory services via LDAP, as well as writing software for getting applications such as Apache, the Squid proxy server, and Cyrus mail servers to check passwords against servers supporting LDAP.
My recent work in this area has included the development of complete Java server software for providing data via the LDAP protocol. The server, originally a part-time open source project, is now the cornerstone of a virtual directory and proxy service product offering from OctetString. However, this book is vendor neutral; all major LDAP vendors are discussed to some extent in the first chapter.
Like many of you, I stumbled onto LDAP by accident. In 1993, I was employed as part of Motorola?s Cellular Infrastructure Group in Arlington Heights, Illinois. Along with a small group of other colleagues, I cofounded one of Motorola?s first web-based intranets.
Unlike today, when most major web sites are dynamic and filled to the brim with personalized content and real-time access to databases and important applications, there were few web-based applications in those days. Sensing the potential use of this new technology, yet realizing that this grass-roots project would not receive funding if we couldn?t adequately expose business information, many team members proceeded to develop applications, such as card catalogs for engineering documents and similar things.
I decided that my small project would be an email directory. As the only person on this project from the IT organization, I was aware of a service provided by corporate mainframes that presented information culled from human resources and local area network (LAN) administrators over a simple protocol called WHOIS.
Using WHOIS, you could open a simple network connection to the server (which in this case resided on a mainframe) and type the data to be used for searching. The search results were returned as free-form text. My application did nothing more than read this text, parse it, and write it out as HTML that could be displayed graphically by a web browser.
It was an instant hit.
I became known at Motorola Cellular as the ?directory? guy, and was instantly pushed onto most of the projects that dealt with directories. At the time, these projects primarily related to email. Email is an important use of directories?after all, if you cannot locate the address of people with whom you need to communicate, a large email infrastructure doesn?t do much good. However, I began to realize that this directory wasn?t just a way to look up information; it was a key storage point for identity information?the only network-accessible place in the company where a person?s email address, login ID, department, name, and manager were linked together. I realized that smart applications could use this information to identify users throughout the company and authorize them based on criteria, such as their department. Those applications could also provide customized presentations based on that same information.
I also knew that as good as this idea was, it would be hard to execute given the limitations of WHOIS, unless we customized each application. At this time, I came into contact with X.500.
Like WHOIS, X.500 is a standard for a kind of directory service. Unlike WHOIS, X.500 is anything but simple. It is a detailed set of standards definitions that seems to describe everything within a 10-mile radius of directory services, including client access, real security, server-to-server communications, and similar areas. Also unlike WHOIS, X.500 comes from the OSI networking world, which was left in the dust in the wake of the Internet explosion and the mass adoption of loosely networked systems built around standards such as TCP/IP.
Nearly every book or article written about LDAP talks about X.500 being perfect except for that dastardly OSI protocol stack, which makes deployment on desktop-class hardware difficult. (Although there is truth to this reasoning, the real reason most X.500 directory projects didn?t take off is that getting the right data into the directory and keeping it up-to-date was difficult?after all, garbage in, garbage out. Similarly, few applications were X.500 aware, partly due to its complexity.) This difficulty spawned LDAP, which was meant to replace X.500?s Directory Access Protocol (DAP) as a client implementation.
After making the move from X.500 to LDAP for the same published reasons everyone else did, the lack of integration tools and directory-enabled applications was obvious. So, I created things like Net::LDAPapi and PerLDAP to glue together information from different sources into the directory. Not long afterward, I wrote the code that allowed users to be identified and authorized to many services, such as web, proxy, and mail.
Today many applications are directory-enabled?so many that these applications drive most new directory deployments, rather than the other way around. People looking at deploying and accessing directories are faced with many difficult choices in design and execution. My goal for this book is to help simplify this complex technology in a way that accelerates your projects and improves your end results.
Since discovering LDAP, I?ve spent nearly every day looking to develop solutions to these types of problems. Much of the time, the solution is centered on creating enterprise directory services. I?ve learned a few things about creating successful directory services. The most critical are:
Although these may seem like insanely simple lessons, let me explain.
Certain methods of access may be more efficient or provide more underlying functionality, but at the end of the day, it is only important that the directory service can share information in a way that clients and applications can use. Today, that standard for sharing information in directory services is LDAP. Therefore, we use LDAP as the primary access protocol throughout this book.
However, many of the more advanced techniques described in parts 2 and 3 of this book will work just as well with another means of access. In fact, part 3 describes the use of Directory Services Markup Language (DSML), which you can use to represent directory services information as XML.
This is not to say that your mother should be installing and configuring your directory servers. It is merely an indication of the relative complexity of configuration versus management.
I cannot stress enough that unless the directory is running in a stand-alone environment where it is the only source of data, there will be effort in getting information into and out of the directory. Unless you understand and make this effort up front, the data in the directory will either be stale and useless or require yet another manual administrative process to keep it up to date.
New technology is coming out that removes some of the technical barriers to splicing information into authoritative directories. However, such technology does not remove the internal political roadblocks and the need for up-front planning that is required in nearly all meaningful directory service deployments.