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!
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
