Understanding LDAP (part 1) - The Sins Of The Fathers... (
Page 5 of 5 )
One of the nice
things about object-oriented programming is inheritance - which means, simply,
that you can take a pre-existing object and use it to spawn a child object which
inherits all the properties of the parent, while simultaneously including any
custom properties you may decide to give it. And your newly-created object can,
in turn, serve as the base for yet another object, and so on ad
infinitum...
In the LDAP world, all this means is that object definitions
can be inherited, thereby freeing schema designers to concentrate on other, more
important things. In the example above, for instance, you'll see that the
definition for the "inetOrgPerson" class does not include attributes for "cn"
and "sn" - even though my original LDAP entry includes these
attributes.
Why, you ask? Because the "inetOrgPerson" class also inherits
some attributes from the "organizationalPerson" class
objectclass ( 2.5.6.7 NAME 'organizationalPerson'
DESC 'RFC2256: an organizational person'
SUP person STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $ destinationIndicator
$
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $
facsimileTelephoneNumber $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l ) )
which, in turn, inherits some attributes (including
the lost-but-now-found "cn" and "sn" attributes) from the "person"
class.
objectclass ( 2.5.6.6 NAME 'person'
DESC 'RFC2256: a person'
SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
In case you're wondering, all these definitions are
LDAP standards and come bundled with most LDAP servers; however, if you have the
time (and necessary knowledge), LDAP also allows you to design your own schema
definitions and include them in your object collection.
You can also
apply more than one object definition to a single entry - consider the following
hybrid:
dn: dc=melonfire, dc=com
objectclass: dcObject
objectclass: organization
dc: melonfire
o: Melonfire
In this case, I've said that the entry is an instance
of the "dcObject" and "organization" classes. Since I've used more than one
object class, the final LDAP entry must be compliant with the rules specified in
each of the referenced class definitions.
Now, while I'd love to go on
and on about the theory behind LDAP, this is, sadly, all we have time for at the
moment (it's also all you really need to know about LDAP, unless you're a geek
with a penchant who likes calculating pi to the nineteenth digit). In the second
part of this article, I'll be putting all this theory to the test, using it to
build a real, live LDAP-based address book for a small office. Make sure you
come back for that!
Note: Examples are illustrative only, and are not
meant for a production environment. Melonfire provides no warranties or support
for the source code described in this article. YMMV!
