Understanding LDAP


LDAP is a proposed standard by the Internet Engineering Task Force (IETF) that helps tie together directory structures from several of its predecessors, such as X.500 (DAP), into a more easily understood and interchangeable format. And although LDAP is continually being advanced via new proposed standards, the core features you'll be using for most development tasks remain, for the most part, unchanged.

NOTE

Currently, LDAP is in its third version (RFCs 22512256), but many new enhancements are currently being proposed and debated by the IETF. To see frontline information regarding this process, visit the IETF's Web site at www.ietf.org/.


The fact that large corporations such as Microsoft, Netscape, Sun, Oracle, and Novell now support LDAP is a compelling reason to begin learning it. In addition, many newer operating systems now include LDAP support as a core feature, making it a usable technology right now.

Directory Structures

To store information in an organized fashion, LDAP uses something called a Directory Information Tree (DIT). This tree is essentially a hierarchical map composed of entries and their corresponding attributes and values. An entry might be a department, division, or single user, and like any tree, LDAP starts at a single point (the root) and expands out into other branches or points until the end of the tree is reached. This type of structure allows LDAP to refer to entries in a unique manner, both quickly and efficiently. Directory trees can often be large and complex. Having a rough idea how this data is organized and accessed will give you a better chance of finding what you're looking for.

To perform a search, you can begin at any point within the directory tree, such as the root or at the department level. Each entry within the directory is called a Distinguished Name (DN), which is used to uniquely refer to that entry. A DN can be a single point within a directory, or it can represent a sequence of entries leading to a specific point in a directory.

Building a DN is one of the aspects of LDAP that confuses first-time users. Because of this, a parallel will be drawn to JavaScript that shows how objects are accessed in JavaScript's Document Object Model (DOM). Follow the next example:

 <script language="JavaScript">  var objReference = document.forms[0].elements[0].value; </script> 

Even if your JavaScript skills aren't up to par, you can still follow that this example starts at the document level and drills down until it reaches a value within a form element. Along each step in the DOM, the parent object is kept as part of the object reference. This value is passed to the objReference variable, which can then be used later in the script.

This same type of "drill-down" process is used for LDAP as well, starting at the top and working down to the value you want to reference. At each step toward this value, you have to concatenate each branch's name and value pair, along with its parent branch's name and value pair, each separated by a comma. The following example shows what one DN might look like:

 user=Dain Anderson, department=Development, division=Orange Whip Studios, country=US 

One key difference between JavaScript references and those in LDAP is the order in which items are listed. Notice in the example above that the most specific references appear first, and the references go up a level as you traverse farther to the right. In other words, the topmost branch is on the far right side of the DN, whereas the lowestyour destination within the treeis on the left side of the DN.

Each branch has a name and value pair, such as country=US, and between each branch, you use a comma as a separator. The branch names in this example are merely samples; the next section explains real names and their meanings.

The completed DN now acts as a guide to the point in the directory tree that is required for your operation. Keep in mind that each entry within the example is a DN in and of itself, and when put together, these DNs can be thought of as a DN sequence.

Name Conventions

To access each DN within a directory tree, you need to use that DN's attribute name. Although potentially hundreds of attribute names may exist, the LDAP definition requires that all implementations provide the same basic set of entries. And depending on the LDAP software you're using, you may encounter inconsistencies from one flavor to the next. Most vendors, however, support the most basic and common directory schema. Table 22.1 shows the commonly used DN attributes and their corresponding meanings.

Table 22.1. DN Attribute Names and Meanings

ATTRIBUTE

MEANING

c

Country. A two-letter ISO 3166 country code, such as US or GB.

l

Locality. The name of a locality, such as a city, county, or other geographic region.

st

State. The full name of a state or province.

street

The physical address of the object to which the entry corresponds, such as an address for package delivery.

o

Organization. The name of an organization, such as a company name.

ou

Organizational unit. The name of an organizational unit, such a department.

title

The title, such as Vice President, of a person in the organizational context.

cn

Common Name. This is the X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it is typically the person's full name.

sn

Surname. This generally represents the family name, or last name, of a person.

givenName

This holds the part of a person's name that is neither the surname nor middle name. It is usually the person's first name.

mail

This represents the email address for the entry. Some LDAP servers use the email attribute instead.




Advanced Macromedia ColdFusion MX 7 Application Development
Advanced Macromedia ColdFusion MX 7 Application Development
ISBN: 0321292693
EAN: 2147483647
Year: 2006
Pages: 240
Authors: Ben Forta, et al

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net