2. Model of Directory User Information
As [X.501] states:
The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'.
An object can be anything which is identifiable (can be named).
An object class is an identified family of objects, or conceivable
objects, which share certain characteristics. Every object
belongs to at least one class. An object class may be a subclass
of other object classes, in which case the members of the former
class, the subclass, are also considered to be members of the
latter classes, the superclasses. There may be subclasses of
subclasses, etc., to an arbitrary depth.
A directory entry, a named collection of information, is the basic unit of information held in the Directory. There are multiple kinds of directory entries.
An object entry represents a particular object. An alias entry provides alternative naming. A subentry holds administrative and/or operational information.
The set of entries representing the DIB are organized hierarchically in a tree structure known as the Directory Information Tree (DIT).
Section 2.1 describes the Directory Information Tree. Section 2.2 discusses the structure of entries. Section 2.3 discusses naming of entries.
Section 2.4 discusses object classes. Section 2.5 discusses attribute descriptions. Section 2.6 discusses alias entries.
2.1. The Directory Information Tree
As noted above, the DIB is composed of a set of entries organized hierarchically in a tree structure known as the Directory Information Tree (DIT); specifically, a tree where vertices are the entries.
The arcs between vertices define relations between entries. If an arc exists from X to Y, then the entry at X is the immediate superior of Y, and Y is the immediate subordinate of X. An entry's superiors are the entry's immediate superior and its superiors. An entry's subordinates are all of its immediate subordinates and their subordinates.
Similarly, the superior/subordinate relationship between object entries can be used to derive a relation between the objects they represent. DIT structure rules can be used to govern relationships between objects.
Note: An entry's immediate superior is also known as the entry's parent, and an entry's immediate subordinate is also known as the entry's child. Entries that have the same parent are known as siblings.
2.2. Structure of an Entry
An entry consists of a set of attributes that hold information about the object that the entry represents. Some attributes represent user information and are called user attributes. Other attributes represent operational and/or administrative information and are called operational attributes.
An attribute is an attribute description (a type and zero or more options) with one or more associated values. An attribute is often referred to by its attribute description. For example, the 'givenName' attribute is the attribute that consists of the attribute description 'givenName' (the 'givenName' attribute type [RFC4519] and zero options) and one or more associated values.
The attribute type governs whether the attribute can have multiple values, the syntax and matching rules used to construct and compare values of that attribute, and other functions. Options indicate subtypes and other functions.
Attribute values conform to the defined syntax of the attribute type.
No two values of an attribute may be equivalent. Two values are considered equivalent if and only if they would match according to the equality matching rule of the attribute type. Or, if the attribute type is defined with no equality matching rule, two values are equivalent if and only if they are identical. (See 2.5.1 for other restrictions.)
For example, a 'givenName' attribute can have more than one value, they must be Directory Strings, and they are case insensitive. A 'givenName' attribute cannot hold both "John" and "JOHN", as these are equivalent values per the equality matching rule of the attribute type.
Additionally, no attribute is to have a value that is not equivalent to itself. For example, the 'givenName' attribute cannot have as a value a directory string that includes the REPLACEMENT CHARACTER (U+FFFD) code point, as matching involving that directory string is Undefined per this attribute's equality matching rule.
When an attribute is used for naming of the entry, one and only one value of the attribute is used in forming the Relative Distinguished Name. This value is known as a distinguished value.
2.3. Naming of Entries
2.3.1. Relative Distinguished Names
Each entry is named relative to its immediate superior. This relative name, known as its Relative Distinguished Name (RDN) [X.501], is composed of an unordered set of one or more attribute value assertions (AVA) consisting of an attribute description with zero options and an attribute value. These AVAs are chosen to match attribute values (each a distinguished value) of the entry.
An entry's relative distinguished name must be unique among all immediate subordinates of the entry's immediate superior (i.e., all siblings).
The following are examples of string representations of RDNs [RFC4514]:
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
The last is an example of a multi-valued RDN; that is, an RDN composed of multiple AVAs.
2.3.2. Distinguished Names
An entry's fully qualified name, known as its Distinguished Name (DN) [X.501], is the concatenation of its RDN and its immediate superior's DN. A Distinguished Name unambiguously refers to an entry in the tree. The following are examples of string representations of DNs [RFC4514]:
[email protected],DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
2.3.3. Alias Names
An alias, or alias name, is "an name for an object, provided by the use of alias entries" [X.501]. Alias entries are described in Section 2.6.
2.4. Object Classes
An object class is "an identified family of objects (or conceivable objects) that share certain characteristics" [X.501].
As defined in [X.501]:
Object classes are used in the Directory for a number of purposes:
- describing and categorizing objects and the entries that
correspond to these objects;
- where appropriate, controlling the operation of the Directory;
- regulating, in conjunction with DIT structure rule
specifications, the position of entries in the DIT;
- regulating, in conjunction with DIT content rule
specifications, the attributes that are contained in entries;
- identifying classes of entry that are to be associated with a
particular policy by the appropriate administrative authority.
An object class (a subclass) may be derived from an object class
(its direct superclass) which is itself derived from an even more
generic object class. For structural object classes, this process
stops at the most generic object class, 'top' (defined in Section
2.4.1). An ordered set of superclasses up to the most superior
object class of an object class is its superclass chain.
An object class may be derived from two or more direct
superclasses (superclasses not part of the same superclass chain).
This feature of subclassing is termed multiple inheritance.
Each object class identifies the set of attributes required to be present in entries belonging to the class and the set of attributes allowed to be present in entries belonging to the class. As an entry of a class must meet the requirements of each class it belongs to, it can be said that an object class inherits the sets of allowed and required attributes from its superclasses. A subclass can identify an attribute allowed by its superclass as being required. If an attribute is a member of both sets, it is required to be present.
Each object class is defined to be one of three kinds of object classes: Abstract, Structural, or Auxiliary.
Each object class is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
2.4.1. Abstract Object Classes
An abstract object class, as the name implies, provides a base of characteristics from which other object classes can be defined to inherit from. An entry cannot belong to an abstract object class unless it belongs to a structural or auxiliary class that inherits from that abstract class.
Abstract object classes cannot derive from structural or auxiliary object classes.
All structural object classes derive (directly or indirectly) from the 'top' abstract object class. Auxiliary object classes do not necessarily derive from 'top'.
The following is the object class definition (see Section 4.1.1) for the 'top' object class:
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
All entries belong to the 'top' abstract object class.
2.4.2. Structural Object Classes
As stated in [X.501]:
An object class defined for use in the structural specification of
the DIT is termed a structural object class. Structural object
classes are used in the definition of the structure of the names
of the objects for compliant entries.
An object or alias entry is characterized by precisely one
structural object class superclass chain which has a single
structural object class as the most subordinate object class.
This structural object class is referred to as the structural
object class of the entry.
Structural object classes are related to associated entries:
- an entry conforming to a structural object class shall
represent the real-world object constrained by the object
class;
- DIT structure rules only refer to structural object classes;
the structural object class of an entry is used to specify the
position of the entry in the DIT;
- the structural object class of an entry is used, along with an
associated DIT content rule, to control the content of an
entry.
The structural object class of an entry shall not be changed.
Each structural object class is a (direct or indirect) subclass of the 'top' abstract object class.
Structural object classes cannot subclass auxiliary object classes.
Each entry is said to belong to its structural object class as well as all classes in its structural object class's superclass chain.
2.4.3. Auxiliary Object Classes
Auxiliary object classes are used to augment the characteristics of entries. They are commonly used to augment the sets of attributes required and allowed to be present in an entry. They can be used to describe entries or classes of entries.
Auxiliary object classes cannot subclass structural object classes.
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry. If no DIT content rule is associated with the structural object class of the entry, the entry cannot belong to any auxiliary object class.
The set of auxiliary object classes that an entry belongs to can change over time.
2.5. Attribute Descriptions
An attribute description is composed of an attribute type (see Section 2.5.1) and a set of zero or more attribute options (see Section 2.5.2).
An attribute description is represented by the ABNF:
attributedescription = attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar
where
Examples of valid attribute descriptions:
2.5.4.0
cn;lang-de;lang-en
owner
An attribute description with an unrecognized attribute type is to be treated as unrecognized. Servers SHALL treat an attribute description with an unrecognized attribute option as unrecognized. Clients MAY treat an unrecognized attribute option as a tagging option (see Section 2.5.2.1).
All attributes of an entry must have distinct attribute descriptions.
2.5.1. Attribute Types
An attribute type governs whether the attribute can have multiple values, the syntax and matching rules used to construct and compare values of that attribute, and other functions.
If no equality matching is specified for the attribute type:
- the attribute (of the type) cannot be used for naming;
- when adding the attribute (or replacing all values), no two
values may be equivalent (see 2.2);
- individual values of a multi-valued attribute are not to be
independently added or deleted;
- attribute value assertions (such as matching in search filters
and comparisons) using values of such a type cannot be
performed.
Otherwise, the specified equality matching rule is to be used to evaluate attribute value assertions concerning the attribute type. The specified equality rule is to be transitive and commutative.
The attribute type indicates whether the attribute is a user attribute or an operational attribute. If operational, the attribute type indicates the operational usage and whether or not the attribute is modifiable by users. Operational attributes are discussed in Section 3.4.
An attribute type (a subtype) may derive from a more generic attribute type (a direct supertype). The following restrictions apply to subtyping:
- a subtype must have the same usage as its direct supertype,
- a subtype's syntax must be the same, or a refinement of, its
supertype's syntax, and
- a subtype must be collective [RFC3671] if its supertype is
collective.
An attribute description consisting of a subtype and no options is said to be the direct description subtype of the attribute description consisting of the subtype's direct supertype and no options.
Each attribute type is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
2.5.2. Attribute Options
There are multiple kinds of attribute description options. The LDAP technical specification details one kind: tagging options.
Not all options can be associated with attributes held in the directory. Tagging options can be.
Not all options can be used in conjunction with all attribute types. In such cases, the attribute description is to be treated as unrecognized.
An attribute description that contains mutually exclusive options shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where "x-foo" and "x-bar" are mutually exclusive, is to be treated as unrecognized.
Other kinds of options may be specified in future documents. These documents must detail how new kinds of options they define relate to tagging options. In particular, these documents must detail whether or not new kinds of options can be associated with attributes held in the directory, how new kinds of options affect transfer of attribute values, and how new kinds of options are treated in attribute description hierarchies.
Options are represented as short, case-insensitive textual strings conforming to the
Procedures for registering options are detailed in BCP 64, RFC 4520 [RFC4520].
2.5.2.1. Tagging Options
Attributes held in the directory can have attribute descriptions with any number of tagging options. Tagging options are never mutually exclusive.
An attribute description with N tagging options is a direct (description) subtype of all attribute descriptions of the same attribute type and all but one of the N options. If the attribute type has a supertype, then the attribute description is also a direct (description) subtype of the attribute description of the supertype and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct (description) subtype of 'cn;lang-de', 'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined in [RFC4519]).
2.5.3. Attribute Description Hierarchies
An attribute description can be the direct subtype of zero or more other attribute descriptions as indicated by attribute type subtyping (as described in Section 2.5.1) or attribute tagging option subtyping (as described in Section 2.5.2.1). These subtyping relationships are used to form hierarchies of attribute descriptions and attributes.
As adapted from [X.501]:
Attribute hierarchies allow access to the DIB with varying degrees
of granularity. This is achieved by allowing the value components
of attributes to be accessed by using either their specific
attribute description (a direct reference to the attribute) or a
more generic attribute description (an indirect reference).
Semantically related attributes may be placed in a hierarchical
relationship, the more specialized being placed subordinate to the
more generalized. Searching for or retrieving attributes and
their values is made easier by quoting the more generalized
attribute description; a filter item so specified is evaluated for
the more specialized descriptions as well as for the quoted
description.
Where subordinate specialized descriptions are selected to be
returned as part of a search result these descriptions shall be
returned if available. Where the more general descriptions are
selected to be returned as part of a search result both the
general and the specialized descriptions shall be returned, if
available. An attribute value shall always be returned as a value
of its own attribute description.
All of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions for user
modification of entry content.
An attribute value stored in an object or alias entry is of
precisely one attribute description. The description is indicated
when the value is originally added to the entry.
For the purpose of subschema administration of the entry, a specification that an attribute is required is fulfilled if the entry contains a value of an attribute description belonging to an attribute hierarchy where the attribute type of that description is the same as the required attribute's type. That is, a "MUST name" specification is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a subtype of 'name'). Likewise, an entry may contain a value of an attribute description belonging to an attribute hierarchy where the attribute type of that description is either explicitly included in the definition of an object class to which the entry belongs or allowed by the DIT content rule applicable to that entry. That is, 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (or by "MUST name").
For the purposes of other policy administration, unless stated otherwise in the specification of the particular administrative model, all of the attribute descriptions in an attribute hierarchy are treated as distinct and unrelated descriptions.
2.6. Alias Entries
As adapted from [X.501]:
An alias, or an alias name, for an object is an alternative name
for an object or object entry which is provided by the use of
alias entries.
Each alias entry contains, within the 'aliasedObjectName'
attribute (known as the 'aliasedEntryName' attribute in X.500), a
name of some object. The distinguished name of the alias entry is
thus also a name for this object.
NOTE - The name within the 'aliasedObjectName' is said to be
pointed to by the alias. It does not have to be the
distinguished name of any entry.
The conversion of an alias name to an object name is termed
(alias) dereferencing and comprises the systematic replacement of
alias names, where found within a purported name, by the value of
the corresponding 'aliasedObjectName' attribute. The process may
require the examination of more than one alias entry.
Any particular entry in the DIT may have zero or more alias names.
It therefore follows that several alias entries may point to the
same entry. An alias entry may point to an entry that is not a
leaf entry and may point to another alias entry.
An alias entry shall have no subordinates, so that an alias entry
is always a leaf entry.
Every alias entry shall belong to the 'alias' object class.
An entry with the 'alias' object class must also belong to an object class (or classes), or be governed by a DIT content rule, which allows suitable naming attributes to be present.
Example:
dn: cn=bar,dc=example,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
cn: bar
aliasedObjectName: cn=foo,dc=example,dc=com
2.6.1. 'alias' Object Class
Alias entries belong to the 'alias' object class.
( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL
MUST aliasedObjectName )
2.6.2. 'aliasedObjectName' Attribute Type
The 'aliasedObjectName' attribute holds the name of the entry an alias points to. The 'aliasedObjectName' attribute is known as the 'aliasedEntryName' attribute in X.500.
( 2.5.4.1 NAME 'aliasedObjectName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].