Let's explore the four models of LDAP which allows LDAP software
to be interoperable, thus allowing for it to be tailored to fit
disparate applications from different vendors:
Security model
Information Model
The information model describes the informational units that go
into the directory, that is, the entries and their types. As we
saw earlier, the entries are the basic building blocks of the
directory, which in turn are composed of attributes. The
attributes of an entry are composed of an attribute type and one
or more values. We design a schema for the directory which
constrains the attributes and the type of attributes. Schemas are
described in the LDIF (LDAP Data Interchange Format).
LDAP Data Interchange Format (LDIF)
LDIF is a standardized text-based format that describes directory
entries. Using the LDIF format, data from one directory can be
exported to another regardless of the actual format the two
directories use for their datastores. For example, we can move
data from a directory that uses GDBM as a back-end datastore to
another directory that uses Oracle's RDBMS as a datastore.
LDIF has been designed with the 'lightweightness' of LDAP in
mind. LDIF is a text format and even binary entries (such as
images) need to be converted to base64 (a text format) before
they can be stored as part of an LDIF definition. Further, the
LDIF format provides a human-readable interface for data stored
within the directory. However, remember that the actual storage
of data within the LDAP server itself is in the format required
by the particular back-end database that it uses for a datastore
and should not be confused with LDIF.
Let's take a look at a sample directory that we shall be using
further when we take a look at developing an LDAP application in
the last section:
This is a typical address book that we would maintain online in
our LDAP directory. Let's take a look at the corresponding LDIF
representation for this directory representation, which will
clarify things a bit:
dn: o=myorg, c=us
objectclass: top
objectclass: organization
o: myorg
dn: mail=nc@myorg.com, o=myorg, c=us
cn: Nikki Cruise
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
l: Arlington
mail: nc@myorg.com
telephonenumber: 123 456 7890
Description: Corporate Evangelist
dn: mail=jc@myorg.com, o=myorg, c=us
cn: James Close
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
l: San Francisco
mail: jc@myorg.com
telephonenumber: 789 456 7890
Description: Dot com dude
dn: mail=mc@myorg.com, o=myorg, c=us
cn: Martha Cain
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
l: Kansas city
mail: mc@myorg.com
telephonenumber: 456 123 7890
Description: Aspiring actress
Here we see an initial top-level entry which represents the node
with the o=myorg label:
dn: o=myorg, c=us
objectclass: top
objectclass: organization
o: myorg
The distinguished name (dn) label within this entry is an
attribute. So are the objectclass and organization
(o) labels. In an earlier discussion we saw that the DN attribute
is the unique identifier for an entry and it traces the path of
the entry from the top-level root. The DN consists of comma-
separated RDNs and usually the left-most RDN is an attribute of
the entry itself. In this case it is the o attribute. Hence
tracing this entry from the top-level root, which is c=us, we
come to the entry itself. Thus the DN of the entry is the string
o=myorg, c=us.
While most DNs contain attributes that are included in the entry,
this is not a requirement, the only requirement being that the
DNs are unique. The objectclass label indicates the object
hierarchy to which the entry belongs. In this case it indicates
that the entry has been derived from the object called
organization.
LDAP Applications - Page 3
Professional PHP4 Programming
LDAP Models (Con't) - Page 5
