| Author |
Topic: Objectclass and Subclassing: Abstract, Structural and Auxiliary Object Class |
|
eLDAP
member
offline  |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
 |
|
|
| Objectclass and Subclassing: Abstract, Structural and Auxiliary Object Class |
Object Classes
In LDAP, an object class defines the set of attributes that can be used to define an entry.
An object class can be one of three types:
Structural: indicates the attributes that the entry may have and where each entry may occur in the DIT. This object class represents the corresponding real world object. Entries must belong to a structural object class, so most object classes are structural object classes.
Auxiliary: indicates the attributes that the entry may have. An auxiliary object class does not represent a real world object, but represents additional attributes that can be associated with a structural object class to supplement its specification. Each entry may belong to only a single structural object class, but may belong to zero or more auxiliary object classes.
Abstract: defined only as a superclass or template for other (structural) object classes. An abstract object class is a way of collecting a set of attributes that will be common to a set of structural object classes, so that these classes may be derived as subclasses of the abstract class rather than being defined from scratch. An entry may not belong to an abstract object class.
|
|
|
|
|
|
|
eLDAP
member
offline  |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| Subclassing: How does LDAP object class grow? |
An object class can be derived from an object class which is itself derived from an even more generic object class. This process stops at the most generic object class, top, which is an abstract object class used as a superclass of all structural object classes. This single chian of subclassing is commonly referred as inheritance.
An object class may be derived from two or more direct superclasses. This feature of subclassing is termed multiple inheritance.
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| Who can acts as superclass or subclass? |
Abstract
|
------------------------
| | |
Abstract Structural Auxiliary
Structural
|
------------------------
| | |
Structural Structural Structural
Auxiliary
|
------------------------
| | |
None None None
As it can be seen from above:
An abstarct object class can subclass any type of class;
A structural object class can only subclass its own type;
An auxiliary object class can not subclass any type of class.
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| LDAP Directory Object Model: rules of contents of an entry |
The directory object model allows an entry to be instantiated from several object classes with the followings rules:
Structural Auxiliary ... Auxiliary
| | |
----------------------------
|
Directory
Entry
An entry shall not belong only to abstract object classes;
An entry shall not belong to more than one structural object class (excluding its superclasses);
Besides being a member of the structural object class, an entry may be optionally a member of one or more auxiliary object classes.
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| A classic example of directory entry |
Here is a classic directory entry
dn: uid=Babs_Jensen,ou=people,dc=mydomain,dc=com
uid: Babs_Jensen
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgperson
cn: Babs Jensen
sn: Jensen
givenname: Barbara
mail: bjensen@example.com
In this structure, the structural object class inetOrgperson inherits from structural organizationalPerson, structural person and eventually the abstract object class top. Therefore, when you assign the inetOrgperson object class to an entry, it automatically inherits the required and allowed attributes from the superior object class.
Here, 'objectClass' is the required attribute specified in top while 'cn' and 'sn' are required attributes specified in person. The rest attributes are defined in MAY lists of the objectclasses.
It should be noted that 'uid' is not required by schema itself, but it MIGHT be required to be present by RDN naming rule. Some LDAP servers, like SunOne and Active Directory, may automatically add the RDN as attribute when built up the entry.
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| A extended architecture of directory entry |
Here is another directory entry
dn: uid=Babs_Jensen,ou=people,dc=mydomain,dc=com
uid: Babs_Jensen
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgperson
objectClass: strongAuthenticationUser
cn: Babs Jensen
sn: Jensen
userCertificate:: GXas3KaSd...
givenname: Barbara
mail: bjensen@example.com
In this structure, a auxiliary object class strongAuthenticationUser is added besides the classic structural object class inetOrgperson. The strongAuthenticationUser specifies that the attribute 'userCertificate' MUST be present for this entry to be valid in the LDAP DIT.
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| What does it look like in schma? |
objectClasses: (
2.5.6.15
NAME 'strongAuthenticationUser'
DESC 'Standard LDAP objectclass'
SUP top
AUXILIARY
MUST ( userCertificate )
X-ORIGIN 'RFC 2256'
)
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| Is 'extensibleObject' an auxiliary objectclass? |
Yes, here is the definition:
objectClasses: (
1.3.6.1.4.1.1466.101.120.111
NAME 'extensibleObject'
DESC 'LDAPv3 extensible object'
SUP top
AUXILIARY
X-ORIGIN 'RFC 2252'
)
As you can see, 'extensibleObject' does not specify any attributes (MUST or MAY) inside its body. This is a very special objectclass which allow for any attributes being legally resides inside its body. In other words, 'extensibleObject' is a super auxiliary objectclass which can legalize any user defined attributes.
For example:
dn: uid=Babs_Jensen,ou=people,dc=mydomain,dc=com
uid: Babs_Jensen
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgperson
objectClass: extensibleObject
cn: Babs Jensen
sn: Jensen
givenname: Barbara
mail: bjensen@example.com
ssn: 333-22-4444
Here, the user defined attribute 'ssn' conforms with schema due to the presence of 'extensibleObject' and thereafter can pass the schema checking.
|
|
|
|
|
|
|
|
Email To Friend | 
Set Alert To This Topic
New Topic | 
Post Reply 
posted on: 08/02/2006 01:27:29 PM
Edit
Quote
Report
Profile
Reply