IBM's XML Enabler: Making the World Safe for XML   Table of contents   Indexes   Building an XML Web Site Production System
Directory services
 IBM 
LDAP
 XML 
 

Accessing LDAP Data with XML

 IBM Corporation 
 North Carolina 
 Research Triangle Park 
 Tidwell, Doug 
 		Doug  Tidwell
Advisory Programmer ,  IBM Corporation  
  Human Interface Group
E20D/500
P.O. Box 12195
Research Triangle Park   ( North Carolina )  27709  
Email: dtidwell@us.ibm.com

Biographical notice

Doug Tidwell is an Advisory Programmer at IBM. He has well over a tenth of a century of programming and technical writing experience, and has been working with XML-like applications for several years. He holds, with special gloves, a Masters Degree in Computer Science from Vanderbilt University and a Bachelors Degree in English from the University of Georgia. His specialty is developing markup-based tools that create user interfaces and simplify data interchange.

 

Introduction

  LDAP, the Lightweight Directory Access Protocol, has become the standard for managing directory data across the Internet. Unfortunately, accessing and managing this information requires more programming skills and network knowledge than most users possess. This paper discusses LDAP directories and their use, along with our attempts to make the full power of an LDAP directory accessible through an XML tag set.
 

LDAP Basics

  LDAP is a directory service, a specialized database that stores detailed information about things such as people, printers, and files. Without a diretory service, this information is often stored in a number of different formats in a number of different places. For example, information about a person might be stored in a phone directory application, in the security management system of a file server, and in a payroll application. This duplication of data leads to maintenance and consistency problems. In addition, programmers building these systems must write different pieces of code that access the same data in several different ways.
  Clearly, a solution that involves a single source for the information and a single access method for it would solve a number of problems. Any changes to the data would only have to be made once, and any application that wanted to access the data would use a single programming interface. LDAP is designed to be this solution.
 

LDAP Terms

  Before we go on, we'll define some common LDAP terms.
 

Directory Tree

  A directory tree defines the hierarchical structure of the items in an LDAP database.
  Here's a sample directory tree. The root entry is o=IBM_US, and the subdirectories ou=users, ou=groups, and ou=admin are contained inside the root entry. In addition, the object identified by cn=Joe Blow is shown beneath the ou=users subdirectory.

Sample directory tree

  We'll discuss all of our LDAP definitions in terms of this figure.
 

Distinguished Name (DN)

  A name that uniquely defines a directory entry within the LDAP database. A DN is similar to a fully-qualified file name in a file system. In our example above, the DN for Joe Blow is "cn=Joe Blow, ou=users, o=IBM_US".
 

Suffix

  A value that identifies the directory tree under which all directory information is stored. In the example above, the suffix for all LDAP information is "o=IBM_US".
 

Root Entry

  The top-most entry in the directory tree. This entry must have a distinguished name that is identical to the suffix. In our example, the root entry is "o=IBM_US".
 

Root Distinguished Name

  A special entry in the directory that has complete access to the database. The root distinguished name is similar to a superuser account.
 

Base Distinguished Name

  Also known as the search base, this is the directory entry from which any searches will occur. In the directory tree figure above, searching for everyone with a last name of "Blow" under the base DN of "ou=users, o=IBM_US" returns the entry for Joe Blow. When searching, only entries located in the subdirectories of the base DN are found.
 

Schema

  The layout of the LDAP database. For each record in the database, certain fields are required. Some fields can contain only one value, others may contain many values. Some types of fields may extend field definitions from other records. All of these things are defined in the LDAP schema.
 

The LDAP API

  There are a number of functions provided by the LDAP API. In this section, we'll discuss the most commonly used features.
 

Searching

  The most commonly used LDAP feature is searching. In address book and "white pages" applications, this feature allows users to retrieve information about a person or group of people.
  To perform an LDAP search, several things are required. The most obvious is the search arguments themselves. This requires some knowledge of the LDAP schema. For example, to search for everyone with a last name of Blow, you would use the search argument sn=Blow. You must know the name of the LDAP attribute you're searching for (in this case, sn, the surname attribute).
  The next required item is the search base. As discussed earlier, the search base identifies the point in the directory tree from which searches take place. This is similar to searching for a file beneath a particular subdirectory in a file system. Although rarely used, there are options to specify how far the search should go; the default is that all subdirectories beneath the search base are searched.
  Other required items relate more to the network connection than to the search itself. The TCP/IP hostname of the LDAP server must be supplied, along with its LDAP port number. In some cases, a distinguished name and password must be passed to the LDAP server. This allows the LDAP server to determine what access the requester has to the information in the database.
 

Adding Records

  The add record operation requires more data to be provided to the LDAP application. Most significantly, because this involves a change to the database, it requires the user to authenticate that they are authorized to make the change.
  To perform this operation, the LDAP database requires the complete distinguished name of the new LDAP record, along with the LDAP subdirectory to which it should be added. As with all LDAP operations, the user must understand the LDAP schema to add a new record. All required fields must be filled in before the new record can be created. Any other constraints defined in the schema must be met as well.
 

Modifying Records

  Modifying an LDAP record is the most complicated operation of those discussed here. When modifying a record, the distinguished name of the record must be given, along with the proper authentication credentials.
  In addition, each LDAP attribute being modified must be given. Along with the value of each attribute, the user must state whether each attribute is to be added, deleted, or changed in the LDAP database. If an LDAP attribute is added, and that attribute can have more than one value, the new value is added to any existing values of the attribute. If an attribute is deleted or modified, the value specified must match the LDAP attribute's value (or one of its values, in the case of a multi-valued attribute).
 

Renaming Records

  Renaming an LDAP record is done by changing its distinguished name. Once a record is renamed, it occupies a different space in the directory tree. This operation requires both the current DN and the new one. If this operation completes successfully, the existing LDAP directory entry is now located in a different subdirectory.
 

Combining XML and LDAP

  Although the LDAP API is a supported by a number of directory vendors, it still requires a certain amount of programming knowledge to use that interface. Given our XML bias, it was only a matter of time before we began to investigate using XML to represent and manipulate the structured data of LDAP. The hierarchical nature of LDAP data is easily modeled through nesting XML tags, and the parameters needed to define LDAP operations can be described with XML tags and attributes as well.
 

Proposed XML Vocabulary for LDAP

  Our goals for the XML vocabulary were:
 
  • Provide access to the most commonly used LDAP functions.
    •  
  • Create a tag set that preserves the structure of the original LDAP data.
    •  
  • Take advantage of the authentication features of LDAP to make sure that users are authorized to perform any requested operations.
    •   With these goals in mind, we created a number of tags. The tags described here contain schema-specific tags that may vary from one LDAP implementation to the next.
      First, we created several tags that define LDAP operations:
     

    <ldap-add>

      This tag adds a new record to the LDAP database. As with all operations that modify the LDAP database, the correct authentication parameters must be passed for this operation to succeed.
     

    <ldap-binding>

      This tag creates a binding to an LDAP database. This allows user requests to be authenticated.
     

    <ldap-delete>

      The <ldap-delete> tag deletes an existing record in the LDAP database.
     

    <ldap-modify>

      This tag allows you to modify an existing LDAP record.
     

    <ldap-modify-rdn>

      Specifies the distinguished name from which the modify operation should take place.
     

    <ldap-search>

      This tag defines the parameters for an LDAP search.
     

    <ldap-template>

      This tag defines a search template that can be used by later search requests. All templates are accessible as long as the server object exists.
      Next, we defined tags to describe the results returned by the LDAP server:
     

    <ldap-error>

      Defines an error returned by the LDAP server. This includes an error code (defined by the LDAP protocol, RFC 2251) and an optional text description.
     

    <ldap-object>

      This tag describes each item returned by an LDAP search operation. Each <ldap-object> tag contains a number of schema-specific tags that uniquely define the LDAP object.
     

    <ldap-results>

      The <ldap-results> tag is a container for the <ldap-error> and <ldap-object> tags. All objects returned by a search appear inside the <ldap-results> tag.
     

    System Architecture

      Once we had decided to represent LDAP data and operations with XML markup, we still had to figure out how to implement a piece of code that would provide this function. Our solution was to create a Java-based proxy that took XML as input, converted that into an LDAP operation, then returned the results from that operation as an XML data stream.

    xmLDAP Architecture

      The figure above illustrates our approach. An XML client application that knows our DTD (not the LDAP API) sends an XML data stream to the xmLDAP proxy. The proxy interprets the XML data stream, converts the information into LDAP API calls, and contacts the LDAP server. The LDAP server returns the results of the operation to the xmLDAP proxy, which converts those data structures to XML markup. Finally, the XML markup representing the LDAP results is returned to the client.
      The Java code is implemented as two classes: One is a simple proxy that takes XML as input, and returns LDAP results as XML markup. The other is a Java servlet that processes parameters delivered through HTTP. This allows us to deliver XML data across the web without violating the Java security model. It also allows us to deliver XML data to a client that has no Java support, such as a dumb terminal or a palmtop.
      A sample application, the xmLDAP Viewer, was created to illustrate how easily LDAP data can be extracted from an LDAP database. The viewer contains an entry field in which XML tags are entered; that XML markup is sent to our xmLDAP proxy, which interacts with the LDAP server and displays the results in a text area. The following figure shows a sample session.

    Sample Interaction with the xmLDAP Viewer

      The power of our xmLDAP architecture is evidenced by the fact that adding LDAP access to this interface required only a single line of code. Obviously a friendlier LDAP front-end would require more code to construct the appropriate XML markup for the user, but the actual LDAP access requires only a single line of code for each product function.
     

    XML Reuse

      One of the most interesting aspects of our schema-based markup is that it enables us to use the results of one xmLDAP operation as the input to another. For example, an LDAP search might return data such as <manager_record>cn=L. Jefe</manager_record> to represent the distinguished name of the manager of a given employee. Using this element as input to another search would return all employees who worked for this particular manager.
      The ability to define search templates also allows reuse of XML-tagged data. A search template defines the LDAP attributes that should be returned by a search, as well as any constraints for that search (surname=Jones, for example). Once a search template is defined, subsequent search operations can refer to the ID of the template to customize the results of the search.
      Finally, the ability to define LDAP bindings in markup allows us to reuse those bindings as well. Our emphasis on reuse in markup is to limit the amount of XML-tagged data that flows across the network, and to improve the usability of the xmLDAP componentry for our users.
     

    Summary

      Our initial work to combine XML and LDAP has given us the ability to integrate LDAP database access into applications much more easily. Although this is a good first step, we plan to extend our efforts to enhance network performance, provide better security, and simplify our tag set even further. Clearly XML and LDAP are two technologies that are very well matched.
     

    Future Research

      There are several topics we would like to consider in the future:
     

    Enterprise JavaBeans (EJB) support

      Wrappering our existing objects in an Enterprise JavaBean would enable us to provide transaction and security features.
     

    Reusable XML/DOM objects

      We plan to investigate reusing either the raw XML-tagged data or the parsed DOM tree representing that data. We believe this could greatly improve network performance.
     

    Acknowledgements

      The ideas in this paper were developed with the technical insights of Jay Unger, David Lection, and Charles Burkett.
    IBM's XML Enabler: Making the World Safe for XML   Table of contents   Indexes   Building an XML Web Site Production System