| Oracle® Fusion Middleware Administrator's Guide for Oracle Unified Directory 11g Release 2 (11.1.2) Part Number E22648-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Unified Directory 11g Release 2 (11.1.2) Part Number E22648-02 |
|
|
PDF · Mobi · ePub |
This chapter describes schema elements in general and illustrates the ways that these schema elements are used in Oracle Unified Directory.
The chapter covers the following topics:
For instructions on viewing the schema using the ldapsearch command, see Section 26.4.1, "Managing Attribute Types" and Section 26.4.2, "Managing Object Classes."
Matching rules are used by Oracle Unified Directory to compare two values for the same attribute, that is, to perform matching operations on them. There are several different types of matching rules, including:
These matching rules are used to determine whether two values are logically equal to each other. Different implementations of equality matching rules can use different criteria for making this determination (for example, whether to ignore differences in capitalization or deciding which spaces are significant).
These matching rules are used to determine the relative order for two values, for example, when evaluating greater-or-equal or less-or-equal searches, or when the results need to be sorted.
These matching rules are used to determine whether a given substring assertion matches a particular value. A substring assertion is composed of at least one element from the following sets: at most one subInitial element, zero or more subAny elements, and at most one subFinal element.
These matching rules are used to determine whether two values are approximately equal to each other. This is frequently based on "sounds like" or some other kind of fuzzy algorithm. Approximate matching rules are not part of the official LDAP specification, but they are included in Oracle Unified Directory for added flexibility.
The following sections describe matching rules:
The matching rule description format is described in RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt), section 4.1.3, in Augmented Backus-Naur Form (ABNF). For more information about ABNF, see RFC 4234 (http://www.ietf.org/rfc/rfc4234.txt) and RFC 5234 (http://www.ietf.org/rfc/rfc5234.txt). This is the format that is used to display matching rules in the matchingRules attribute of the schema subentry, and it shows the properties that can be associated with a matching rule. The following example shows the definition of the matching rule description format:
MatchingRuleDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "SYNTAX" SP numericoid ; assertion syntax extensions WSP RPAREN ; extensions
The matching rule description includes these elements:
numericoidThe numeric OID is used to uniquely identify the matching rule in Oracle Unified Directory. Every matching rule must have a unique OID.
NAMEThe name elements are human-readable names assigned to the matching rule that can be used to refer to it in place of the OID. A matching rule is not required to have any human-readable names. If it has only a single name, then it is enclosed in single quotes. If there are multiple names for a matching rule, each is enclosed in single quotes with spaces between the names, and parentheses around the entire set of names.
DESCThe description element is a human-readable description for the matching rule. There can be at most one description, and if it is present, it should be enclosed in single quotation marks.
OBSOLETEThe OBSOLETE flag indicates whether this matching rule should be considered available for use. If a matching rule is marked OBSOLETE, then it should not be possible to create any new attribute types or matching rule uses that reference this matching rule.
SYNTAXThe syntax element identifies the attribute syntax with which the matching rule is associated. This is used to indicate the acceptable format for values on which the matching rule operates. More information about attribute syntaxes can be found in Section 8.2, "Understanding Attribute Syntaxes." The syntax OID must be included in all matching rule descriptions.
The extensions for a matching rule can be used to identify other properties for that matching rule that might not be included in the standard definition. Oracle Unified Directory does not currently support any extensions for use in matching rules.
For example, the following is the matching rule description for the standard caseIgnoreMatch matching rule:
( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
In this case, the OID is 2.5.13.2. There is one name, which is caseIgnoreMatch. There is no description. The OID of the associated syntax is 1.3.6.1.4.1.1466.115.121.1.15 (which is the Directory String syntax). There are no extensions.
There are a number of matching rules defined in LDAP, both in the core protocol specification as well as in other related RFCs and Internet Drafts. Many of these matching rules are defined in RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt) (LDAP Syntaxes and Matching Rules), in section 4.2. Some of the most commonly used matching rules include:
caseIgnoreMatch, caseIgnoreOrderingMatch, caseIgnoreSubstringsMatchThese are equality, ordering, and substring matching rules, respectively, that ignore differences in capitalization and also treat multiple consecutive spaces as a single space.
caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatchThese are equality, ordering, and substring matching rules, respectively, that treat values in a case-sensitive manner but do treat multiple consecutive spaces as a single space.
octetStringMatch, octetStringOrderingMatch, octetStringSubstringsMatchThese are equality, ordering, and substring matching rules, respectively, that perform byte-for-byte comparisons of the values, treating them as binary data rather than strings.
numericStringMatch, numericStringOrderingMatch, numericStringSubstringsMatchThese are equality, ordering, and substring matching rules, respectively, that operate on values that start with a numeric digit, and contain only numeric digits and spaces. Spaces are ignored when performing matching with these matching rules.
distinguishedNameMatchThis is an equality matching rule that operates on distinguished name (DN) values. It ignores spaces around the commas or semicolons that separate DN components, spaces around plus signs that separate RDN components, and spaces around equal signs that separate RDN attribute type names from their corresponding values. Differences in capitalization are ignored for attribute type names. Equality matching for attribute values is performed using the equality matching rule for the corresponding attribute type.
doubleMetaphoneApproximateMatchThis is an approximate matching rule that uses the double metaphone algorithm to perform a "sounds like" comparison. Note that this matching rule is not part of any official LDAP specification, but it is included in Oracle Unified Directory for added flexibility.
Oracle Unified Directory provides two matching rules for performing a match on relative dates in Appendix D, "generalized time" attributes, relativeTimeLTOrderingMatch and relativeTimeGTOrderingMatch, as defined here:
( 1.3.6.1.4.1.26027.1.4.6 NAME ( 'relativeTimeLTOrderingMatch''relativeTimeOrderingMatch.lt' ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ( 1.3.6.1.4.1.26027.1.4.5 NAME ( 'relativeTimeGTOrderingMatch' 'relativeTimeOrderingMatch.gt' ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
The syntax applies to attributes with a GeneralizedTime syntax, but it does not take a generalized time string. Instead it takes an offset in the format of [+|-]number[unit] where:
+|-Specifies a time in the past or future. A positive offset (+) computes a time in the future compared to the current time, and a negative offset (-) computes a time in the past compared to the current time. The default value is positive (+).
Specifies the number of time units as a positive integer
Specifies the time unit as a single letter, s, m, h, d, or w, for seconds, minutes, hours, days, or weeks
When processing the filter, the server computes the current GMT time, adds the offset and compares the attribute value with the new computed value.
The following example represents pwdExpirationTime >= (Now + 5 days).
(pwdExpirationTime:1.3.6.1.4.1.26027.1.4.5:=5d)
Similarly, the following example represents pwdExpirationTime <= (Now + 5 days).
(pwdExpirationTime:1.3.6.1.4.1.26027.1.4.6:=5d)
Oracle Unified Directory provides the partialDateAndTimeMatchingRule matching rule for performing a substring match on dates in Appendix D, "generalized time" attributes:
( 1.3.6.1.4.1.26027.1.4.7 NAME 'partialDateAndTimeMatchingRule' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
This matching rule applies to attributes with a GeneralizedTime syntax, but the value is not a generalized time. Instead, it specifies a pattern for the date, composed of one or more sequences of an integer followed by a tag. The currently supported tags are Y, M, D, h, m, and s.
The following examples use the attribute birthDate (described in http://tools.ietf.org/html/draft-gryphon-ldap-schema-vcard4-00) with the following definition:
attributeTypes: ( 1.3.6.1.4.1.33592.1.3.2 NAME 'birthDate' DESC 'birthday' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX .3.6.1.4.1.1466.115.121.1.24 USAGE userApplications SINGLE-VALUE )
For example, the following filter matches all users born on September 21st.
(birthDate:1.3.6.1.4.1.26027.1.4.7:=09M21D)
As another example, the following filter matches all users born in 1965:
(birthDate:1.3.6.1.4.1.26027.1.4.7:=1965Y)
The following search operation returns all entries with a birthday the fourteenth day of any month:
$ ./ldapsearch -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file \ -b "dc=example,dc=com" \ "(birthDate:1.3.6.1.4.1.26027.1.4.7:=14D)" birthDate
One of the tasks that most matching rules need to perform is value normalization. This is the process of transforming a given value to a form that can be used to compare values efficiently. In most cases, the normalization process should reduce all logically equivalent values to the same string so that a very simple string comparison can be performed to determine whether the strings are equal. For example, the caseIgnoreMatch matching rule typically normalizes values by converting all characters to lowercase and replacing occurrences of multiple consecutive spaces with a single space. A more complicated example is the distinguishedNameMatch matching rule, which removes all unnecessary spaces (for example, around commas, equal signs, and plus signs), converts all attribute types to lowercase, and then uses the appropriate matching rules to normalize the attribute values for each RDN component.
Note that in some cases, normalization alone is not sufficient for determining whether two values are logically equivalent. This is particularly true for cases in which the value is transformed, and there can be multiple different transformations for the same value.
Attribute syntaxes are essentially data type definitions. The syntax for an attribute type indicates the type of data meant to be held by the corresponding values. This can be used to determine whether a particular value is acceptable for a given attribute, as well as to provide information about how Oracle Unified Directory should interact with existing values.
Oracle Unified Directory supports the ability to reject values that violate the associated attribute syntax, and this is the default behavior for the purposes of standards compliance. It is possible to disable this attribute syntax checking completely if necessary, but it is also possible to accept values that violate the associated syntax but log a warning message to Oracle Unified Directory's error log every time this occurs. However, if attributes are allowed to have values that violate their associated syntax, matching operations might not behave as expected with such values. For information about disabling schema checking, see Section 26.2, "Configuring Schema Checking."
The following sections discuss attribute syntax:
The attribute syntax description format is described in RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt), section 4.1.5, as shown in this example:
SyntaxDescription = LPAREN WSP numericoid ; object identifier [ SP "DESC" SP qdstring ] ; description extensions WSP RPAREN ; extensions
The attribute syntax description includes these elements:
numericoidThe numeric OID used to uniquely identify the attribute syntax in Oracle Unified Directory.
DESCAn optional description for the syntax. If it is provided, then it must be enclosed in single quotation marks.
An optional set of extensions for the attribute syntax. Oracle Unified Directory supports the following extensions:
X_PATTERN: Specifies that the attribute uses the regular expression syntax. See Section 8.2.3, "The Pattern-Matching Syntax Extension" for more information.
X-ENUM: Specifies that the attribute uses the enumerated syntax. See Section 8.2.4, "The Enumeration Syntax Extension" for more information.
X-SUBST: Specifies that the attribute uses the substitution syntax. See Section 8.2.5, "Substitution Syntax Extension" for more information.
The following example shows the attribute syntax description for the standard directory string syntax:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
In this case, the OID is 1.3.6.1.4.1.1466.115.121.1.15, and the description is Directory String. This example specifies no extensions.
There are a number of attribute syntaxes defined in LDAP, both in the core protocol specification and in other related RFCs and Internet Drafts. Many of these attribute syntaxes are defined in RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt) (LDAP Syntaxes and Matching Rules) in section 3.3. Some of the most commonly used attribute syntaxes include:
The Directory String syntax is used to hold general-purpose string values containing one or more UTF-8 characters. Technically, empty values (that is, those with zero characters) are not allowed. Because Oracle Directory Server Enterprise Edition has historically allowed empty values, Oracle Unified Directory offers a configuration option that can be used to allow it as well although it is disabled by default for standards compliance.
The IA5 String syntax is used to hold string values based on the IA5 character set, which is also known as the ASCII character set.
The Printable String syntax is used to hold string values that contain one or more characters from the set of uppercase and lowercase letters, numeric digits, single quotes, left and right parentheses, plus sign, comma, hyphen, period, and equal sign.
The Boolean syntax is used to hold values of either TRUE or FALSE. No other values are allowed for attributes with this syntax.
The Integer syntax is used to hold integer values, which must contain at least one digit. It can start with a hyphen to indicate a negative value. Zero can be used as the first digit only when the value is zero.
The Octet String syntax is used to hold a set of zero or more bytes. It has been used to replace the former Binary syntax.
The DN syntax is used to hold distinguished name values, comprised of zero or more RDN components. Values should be in the format specified in RFC 4514 (http://www.ietf.org/rfc/rfc4514.txt) (LDAP String Representation of Distinguished Names).
The X-PATTERN attribute syntax extension can be used to define new string syntaxes with values restricted by one or more regular expressions. The following example adds an X-PATTERN attribute syntax to the schema.
$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file dn: cn=schema changetype: modify add: ldapsyntaxes ldapSyntaxes: ( 1.3.6.1.4.1.32473.1 DESC 'Host and Port in the format of HOST:PORT' X-PATTERN '^[a-zA-Z][a-zA-Z0-9-]+:[0-9]+$' )
This new syntax can be used to define attributes and object classes, as shown in the following example.
$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.32473.2 NAME 'example-attr-regex' SYNTAX 1.3.6.1.4.1.32473.1 ) - add: objectclasses objectclasses: ( 1.3.6.1.4.1.32473.3 NAME 'exampleOCregex' SUP top AUXILIARY MUST example-attr-regex) -
Values for example-attr-regex attributes must match the defined pattern, or the server rejects them. The following attribute fits pattern defined in the example syntax, so the server accepts it:
example-attr-regex: localhost:389
The following attribute is rejected because it does not include the required colon and numeric string:
localhost
The following attribute is rejected because it contains periods (.), which are not specified as part of the HOST component:
host.domain.com:389
The X-ENUM attribute syntax extension can be used to define new string syntaxes with values restricted to a set of defined, ordered values. The following example defines an X-ENUM attribute to the schema.
$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file dn: cn=schema changetype: modify add: ldapsyntaxes ldapSyntaxes: ( 1.3.6.1.4.1.32473.4 DESC 'Day Of The Week' X-ENUM ( 'monday' 'tuesday' 'wednesday' 'thursday' 'friday' 'saturday' 'sunday' ) )
This new syntax can be used to define attributes and object classes, as shown in the following example.
$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.32473.5 NAME 'example-attr-enum' SYNTAX 1.3.6.1.4.1.32473.4 ) - add: objectclasses objectclasses: ( 1.3.6.1.4.1.32473.6 NAME 'exampleOCenum' SUP top AUXILIARY MUST example-attr-enum)
Values for example-attr-enum attributes must match the defined pattern, or the server rejects them.
Enumerated values are not case-sensitive, so both of the following examples are accepted:
example-attr-enum: thursday example-attr-enum: Thursday
Enumerated attribute values are literal (and not internationalized), so the following example does not match the pattern and is rejected, regardless of any semantic equivalence:
example-attr-enum: jeudi
The defined values specify an order, so enumerated attributes can be used in relative comparison filters, as shown in the following example:
(example-attr-enum>=wednesday)
The preceding comparison filter matches, for example, a value of thursday. The comparison is based on the order of the enumerated values, and ASCII values are not applicable in this case.
The X-SUBST attribute syntax extension can be used to define new string syntaxes with values in terms of existing syntaxes. It is provided for use when extending the native directory server schema with a non-standard schema (or an external schema) that uses syntaxes not supported by Oracle Unified Directory. Instead of altering the imported schema, extend it with the X-SUBST extension to instruct Oracle Unified Directory to treat values in terms of a supported syntax.
The following example defines a new syntax, AttCertPath, in terms of an existing syntax, 1.3.6.1.4.1.1466.115.121.1.15, directory string. This change must be made under cn=schema.
$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema ldapSyntaxes: ( 1.3.6.1.4.1.4203.666.11.10.2.4 DESC 'AttCertPath' X-SUBST '1.3.6.1.4.1.1466.115.121.1.15' )
This feature can be useful during migration and can lessen the impact on the schema. For example, during migration to Oracle Unified Directory, an incoming schema can contain attribute definitions that use an undefined syntax. The X-SUBST attribute syntax extension provides a means to define those missing syntaxes in terms of other, more general syntaxes. With this capability, the schema and data can be migrated without the need to modify the schema or data or to implement new syntaxes.
Attribute types define the set of attributes that can be used in Oracle Unified Directory and how operations involving those attributes should be conducted. Among other things, it combines an attribute syntax and set of matching rules with a unique OID and human-readable names.
The following sections describe attribute types:
The attribute type description format is described in RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt), section 4.1.2 as shown here:
AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; supertype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions
usage = "userApplications" / ; user
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational
The attribute type description includes these elements:
numericoidThe numeric OID used to uniquely identify the attribute type in Oracle Unified Directory. Although the specification requires a numeric OID, Oracle Unified Directory also allows a non-numeric OID for the purpose of convenience and better compatibility with Oracle Directory Server Enterprise Edition. In this case, the non-numeric OID should be the same as the name of the attribute type followed by the string -oid.
NAMEAn optional set of human-readable names that can also be used to refer to the attribute type. If there is a single name, then it should be enclosed in single quotes. If there are multiple names, then they should each be enclosed in single quotes separated by spaces, and the entire set of names should be enclosed in parentheses.
DESCAn optional human-readable description. If there is a description, then it should be enclosed in single quotation marks.
OBSOLETEAn optional OBSOLETE flag that can be used to indicate whether the attribute type is active. If an attribute type is marked as OBSOLETE, then it means that it should not be referenced by any new elements created in Oracle Unified Directory.
SUPAn optional reference to the superior attribute type. If there is a superior type, then it may be referenced by either its OID or any of its human-readable names.
EQUALITYAn optional equality matching rule definition. If a specific equality matching rule is provided, then it can be referenced by either its OID or any of its human-readable names. If no equality matching rule is given, then the attribute type uses the default equality matching rule for the associated attribute syntax. If the attribute syntax does not have a default equality matching rule, then equality matching operations are not allowed for attributes of that type.
ORDERINGAn optional ordering matching rule definition. If a specific ordering matching rule is provided, then it can be referenced by either its OID or any of its human-readable names. If no ordering matching rule is given, then the attribute type uses the default ordering matching rule for the associated attribute syntax. If the attribute syntax does not have a default ordering matching rule, then ordering matching operations are not allowed for attributes of that type.
SUBSTRAn optional substring matching rule definition. If a specific substring matching rule is provided, then it can be referenced by either its OID or any of its human-readable names. If no substring matching rule is given, then the attribute type uses the default substring matching rule for the associated attribute syntax. If the attribute syntax does not have a default substring matching rule, then substring matching operations are not allowed for attributes of that type.
SYNTAXAn optional attribute syntax for use with the attribute type. If it is provided, then it should be given as a numeric OID. The syntax identifier can also optionally contain an integer value enclosed in curly braces directly following the OID (without any spaces between the last digit of the OID and the opening curly brace), which may be used to suggest a minimum upper bound on the length of values for attributes of that type. Oracle Unified Directory does not enforce any maximum length restrictions for attribute values, so if a length is given, then it is ignored.
SINGLE-VALUEAn optional SINGLE-VALUE flag that indicates that attributes of that type are allowed to have only a single value in any entry in which they appear. If this flag is not present in the attribute type description, then attributes of that type are allowed to have multiple distinct values in the same entry.
COLLECTIVEAn optional COLLECTIVE flag that indicates that the attributes of that type are assigned their values by virtue in their membership in some collection. Collective attributes are described in RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt) (Collective Attributes in LDAP) and are one of the types of virtual attributes that are supported in Oracle Unified Directory.
NO-USER-MODIFICATIONAn optional NO-USER-MODIFICATION flag that indicates that values of attributes of that type cannot be modified by external clients (that is, the values can be modified only by internal processing within Oracle Unified Directory).
USAGEAn optional usage specification that indicates how the attribute type is to be used. The following attribute usages are allowed:
userApplications — Used to store user data.
directoryOperation — Used to store data required for internal processing within Oracle Unified Directory.
distributedOperation — Used to store operational data that must be synchronized across servers in the topology.
dSAOperation — Used to store operational data that is specific to a particular directory server and should not be synchronized across the topology.
An optional set of extensions for the attribute type. Oracle Unified Directory currently uses the following extensions for attribute types:
X-ORIGIN — Provides information about where the attribute type is defined (for example, whether it is defined by a particular RFC or Internet Draft or whether it is defined within the project).
X-SCHEMA-FILE — Indicates which schema file contains the attribute type definition.
X-APPROX — Indicates which approximate matching rule should be used for the attribute type. If this is specified, then its value should be the name or OID of a registered approximate matching rule.
For example, the following is the attribute type description for the standard uid attribute type:
( 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256}
X-ORIGIN 'RFC 4519' )
In this case, the OID is 0.9.2342.19200300.100.1.1. There is a single human-readable name of uid. The caseIgnoreMatch rule should be used for equality matching, and the caseIgnoreSubstringsMatch rule should be used for substring matching. The attribute type uses the directory string syntax with a suggested minimum upper bound of 256 characters, and the attribute type definition was taken from RFC 4519 (http://www.ietf.org/rfc/rfc4519.txt). There is no description or superior type specified. The attribute type is not marked OBSOLETE, SINGLE-VALUE, COLLECTIVE, or NO-USER-MODIFICATION. There is no ordering matching rule specified, which means that Oracle Unified Directory falls back on the default ordering rule used by the directory string syntax. There is no X-APPROX extension to specify the approximate matching rule so the default approximate rule for the directory string syntax is used there as well.
One attribute type can reference another as its superior type. This has two primary effects:
The matching rule and attribute syntax specifications from the superior attribute type can be inherited by the subordinate type if the subordinate does not override the superior definition. For example, if the superior attribute type uses the IA5 String syntax, then the subordinate attribute type also uses the IA5 String syntax unless its definition overrides that by specifying an alternate syntax. According to the specification in RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt), section 2.5.1, an attribute type can have a different syntax than its superior type only if the syntax for the subordinate type is a refinement of (that is, allows a subset of the values of) the syntax for the superior attribute type.
The OID, any of the human-readable names associated with the superior attribute type, or both can be used to collectively reference all of the subordinate types. For example, the name attribute type is referenced as the superior type for the cn, sn, c, l, st, o, ou, title, givenName, initials, generationQualifier, and dmdName attribute types. Therefore, a filter of (name=test)should match an entry if any attribute with one of those types has a value of test.
A subordinate attribute type cannot have a different usage than its superior type. That is, if the superior type is userApplications, then the subordinate type must also be userApplications. Similarly, if a superior type is declared COLLECTIVE, then the subtype must also be COLLECTIVE, but if the superior type is not COLLECTIVE, then the subordinate type must also not be COLLECTIVE.
At the present time, the mechanism used to handle attribute types varies from the LDAPv3 specification in the following ways:
The LDAPv3 specification states that a subordinate attribute type must have the same syntax as the superior type, or a refinement of that syntax. Oracle Unified Directory does not enforce this constraint because it does not have any way to determine whether one attribute syntax is a refinement of the syntax of the supertype.
The synchronization subsystem does not take attribute usage into account (for example, so that attribute types with a usage of dSAOperation are not synchronized).
Object classes are essentially named sets of attribute types that can be used to control the type of data that can be stored in entries. Note that the terms "object class" and "objectclass" (that is, with and without a space between the words) are generally used interchangeably.
The following sections describe object classes:
The object class description format is described in RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt), section 4.1.1.
ObjectClassDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "SUP" SP oids ] ; superior object classes [ SP kind ] ; kind of class [ SP "MUST" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types extensions WSP RPAREN kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
The object class description includes these elements:
numericoidThe numeric OID used to uniquely identify the object class in Oracle Unified Directory. Although the specification requires a numeric OID, Oracle Unified Directory also allows a non-numeric OID for the purpose of convenience and better compatibility with the Oracle Directory Server Enterprise Edition. In this case, the non-numeric OID should be the same as the name of the object class followed by the string -oid.
NAMEAn optional set of human-readable names that can be used to refer to the object class. If there is a single name, then it should be enclosed in single quotes. If there are multiple names, then they should each be enclosed in single quotes separated by spaces, and the entire set of names should be enclosed in parentheses.
DESCAn optional human-readable description. If there is a description, then it should be enclosed in single quotation marks.
OBSOLETEAn optional OBSOLETE flag that can be used to indicate whether the object class is active. If an object class is marked as OBSOLETE, then it should not be referenced by any new elements created in Oracle Unified Directory.
SUPAn optional set of one or more superior classes for the object class. Note that although technically the specification allows an object class to have multiple superior classes, Oracle Unified Directory currently only supports a single superior class. In this case, the SUP keyword should be followed by a space and the name or OID of the superior class. If there are multiple superior classes, then they should be separated by dollar signs and the entire set of superior classes should be enclosed in parentheses.
kindAn optional keyword that specifies the kind of object class that is being defined. If this is specified, then it must be one of ABSTRACT, STRUCTURAL, or AUXILIARY. If no value is specified, then the object class is considered STRUCTURAL.
MUSTAn optional set of attribute types for attributes that are required to be present (that is, have at least one value) in entries with that object class. If there is only a single required attribute, then the MUSTkeyword should be followed by the name or OID of that attribute type. If there are multiple required attribute types, then they should be separated by dollar signs and the entire set of required attribute types should be enclosed in parentheses.
MAYAn optional set of optional attribute types for attributes that are allowed (but not required) to be present in entries with that object class. If there is only a single optional attribute, then the MAYkeyword should be followed by the name or OID of that attribute type. If there are multiple optional attribute types, then they should be separated by dollar signs and the entire set of optional attribute types should be enclosed in parentheses.
An optional set of extensions for the object class. Oracle Unified Directory currently uses the following extensions for object classes:
X-ORIGIN — Provides information about where the object class is defined (for example, whether it came from a particular RFC or Internet Draft or if it is defined within the project).
X-SCHEMA-FILE — Indicates which schema file contains the object class definition (This extension is generally used for internal purposes only and is exposed to clients.)
For example, the following is the object class description for the standard person object class:
( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) X-ORIGIN 'RFC 4519' )
In this case, the OID is 2.5.6.6. There is a single human-readable name of person. The superior class is top. The kind is STRUCTURAL. Any entry containing the person object class is required to include the sn and cn attributes and is allowed to include the userPassword, telephoneNumber, seeAlso, and description attributes. The object class definition is taken from RFC 4519 (http://www.ietf.org/rfc/rfc4519.txt). There is no description, and the object class is not considered OBSOLETE.
As described in Section 8.4.1, "Object Class Description Format," all object classes must have a kind of either ABSTRACT, STRUCTURAL, or AUXILIARY:
ABSTRACT object classes are intended only to be extended by other object classes. An entry must not contain any abstract class unless it also contains a structural or auxiliary class that derives from that abstract class (that is, includes a non-abstract object class which has the abstract class in its inheritance chain). All entries must contain at least the top abstract object class in the inheritance chain for their structural class. They may or may not contain other abstract classes in the inheritance chains for their structural class or any of their auxiliary classes.
STRUCTURAL object classes are intended to define the crux of what an entry represents. Every entry must include exactly one structural object class chain, and the root of that chain must ultimately be the top abstract object class. The structural object class for an entry cannot be changed.
AUXILIARY object classes are intended to define additional qualities of entries. An entry can contain zero or more auxiliary classes, and the set of auxiliary classes associated with an entry can change over time.
The model represented by object class kinds translates very neatly to the model used by the Java programming language. Abstract LDAP object classes map directly to Java abstract classes, auxiliary LDAP object classes map directly to Java interfaces, and structural LDAP object classes map directly to Java concrete (non-abstract) classes. Just as Java classes must extend exactly one superclass but can implement any number of interfaces, so must LDAP entries contain exactly one structural class chain but can include any number of auxiliary class chains. Similarly, just as it is not possible to directly instantiate an abstract Java class, it is also not possible to create an LDAP entry containing only abstract object classes.
Oracle Directory Server Enterprise Edition has never enforced many of the restrictions noted here around object class kinds. In particular, it would allow the creation of entries that did not contain any structural object class chain and would also allow the creation of entries containing multiple structural object class chains. This means that deployments using Oracle Directory Server Enterprise Edition can contain entries that violate this constraint. Oracle Unified Directory does not allow this behavior by default, but for the sake of compatibility with existing Oracle Directory Server Enterprise Edition deployments, it is possible to configure Oracle Unified Directory to allow entries to violate this constraint, optionally writing a message to Oracle Unified Directory's error log each time this condition is detected. However, if there are entries that do not contain exactly one structural object class, then some schema elements like DIT content rules that depend on this constraint might not work as expected in all cases. To configure Oracle Unified Directory to accept these kinds of schema violations, set the single-structural-objectclass-behavior property of the global configuration. For more information, see "Global Configuration" in the Oracle Unified Directory Configuration Reference.
As specified in Section 8.4.1, "Object Class Description Format," object classes can have zero or more superior classes (although at the present time, Oracle Unified Directory supports at most one superior class). If an object class references a superior class, then all of the required and optional attributes associated with that superior class are also associated with the subordinate class.
The following restrictions exist for object class inheritance:
ABSTRACT object classes can inherit only from other abstract classes. They cannot be subordinate to structural or auxiliary classes.
STRUCTURAL object classes can inherit only from abstract classes or other structural classes. They cannot be subordinate to auxiliary object classes.
AUXILIARY object classes can inherit only from abstract classes or other auxiliary classes. They cannot be subordinate to structural object classes.
All STRUCTURAL object classes must ultimately inherit from the top abstract object class. The net effect of this is that every entry in Oracle Unified Directory must include the top object class and so must also include the objectClass attribute type, which is required by the top object class).
The mechanism used to handle object classes varies from the LDAPv3 specification in that object classes are allowed to have at most one superior class, whereas the specification allows multiple superior classes in some cases.
Name forms can be used to define a mechanism for naming entries in Oracle Unified Directory. In particular, a name form specifies one or more attribute types that must be present in the RDN of an entry with a given structural object class. A name form can also specify zero or more attribute types, which can optionally be present in the RDN.
Each structural object class defined in Oracle Unified Directory schema can be associated with one or more name forms. If a name form is defined for a given structural object class, then the associated name form is enforced for any add or modify DN operations for entries containing that object class. If a structural object class is not associated with a name form, then any attribute type that is allowed to exist in the target entry can be used as a naming attribute type.
The name form description format is described in RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt), section 4.1.7.2, as shown here:
NameFormDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "OC" SP oids ; structural object classes SP "MUST" SP oids ; attribute types [ SP "MAY" SP oids ] ; attribute types extensions WSP RPAREN ; extensions
The name form description includes these elements:
numericoidThe numeric OID used to uniquely identify the name form in Oracle Unified Directory. Although the specification requires a numeric OID, Oracle Unified Directory also allows a non-numeric OID for the purpose of convenience. In this case, the non-numeric OID should be the same as the name of the name form followed by the string -oid.
NAMEAn optional set of human-readable names that can be used to refer to the name form. If there is a single name, then it should be enclosed in single quotes. If there are multiple names, then they should each be enclosed in single quotes separated by spaces, and the entire set of names should be enclosed in parentheses.
DESCAn optional human-readable description. If a description is present, then it should be enclosed in single quotation marks.
OBSOLETEAn optional OBSOLETE flag that can be used to indicate whether the name form is active. If a name form is marked as OBSOLETE, then it should not be in effect within Oracle Unified Directory, nor should it be possible to create any other elements that depend on it.
OCThe names or OIDs of the structural object classes with which the name form is associated.
MUSTThe names or OIDs of one or more attribute types that must be present in the RDN for any entry with the specified structural class. If there is only a single required attribute type, then only its name or OID needs to be given. If there are multiple required attribute types, then they should be separated by spaces and dollar signs, and the entire set of required attribute types should be enclosed in parentheses.
MAYThe names or OIDs of zero or more attribute types that can optionally be present in the RDN for any entry with the specified structural class. If there is only a single optional attribute type, then only its name or OID needs to be given. If there are multiple optional attribute types, then they should be separated by spaces and dollar signs, and the entire set of optional attribute types should be enclosed in parentheses.
An optional set of extensions for the name form. Oracle Unified Directory currently uses the following extensions for name forms:
X-ORIGIN — Provides information about where the name form is defined (for example, whether it came from a particular RFC or Internet Draft or whether it is defined within the project.).
X-SCHEMA-FILE — Indicates which schema file contains the name form definition (This extension is generally used for internal purposes only and is exposed to clients.)
For example, the following is the name form description for the uddiBusinessEntityNameForm name form defined in RFC 4403 (http://www.ietf.org/rfc/rfc4403.txt):
( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm' OC uddiBusinessEntity MUST ( uddiBusinessKey ) X-ORIGIN 'RFC 4403' )
In this case, the numeric OID is 1.3.6.1.1.10.15.1 and the human-readable name is uddiBusinessEntityNameForm. Entries with the uddiBusinessEntity structural object class are required to use uddiBusinessKey as their only RDN attribute type. There is no description, nor are there any other attribute types that can optionally be included in the associated entries. The name form is not marked OBSOLETE.
DIT content rules provide a mechanism for defining the content that can appear in an entry. At most one DIT content rule can be associated with an entry based on its structural object class. If such a rule exists for an entry, then it works in conjunction with the object classes contained in that entry to define which attribute types must, may, and must not be present in the entry, as well as which auxiliary classes that it may include.
The following sections describe DIT content rules:
The DIT content rule description format is described in RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt), section 4.1.6, as shown here:
DITContentRuleDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "AUX" SP oids ] ; auxiliary object classes [ SP "MUST" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types [ SP "NOT" SP oids ] ; attribute types extensions WSP RPAREN ; extensions
The DIT content rule description includes these elements:
numericoidThe numeric OID of the structural object class with which the DIT content rule is associated. Although the specification requires a numeric OID, this numericoid should match the OID specified for the associated object class, so if the object class OID was non-numeric, then this OID should be as well.
NAMEAn optional set of human-readable names used to refer to the DIT content rule. If there is a single name, then it should be enclosed in single quotes. If there are multiple names, then they should each be enclosed in single quotes separated by spaces, and the entire set of names should be enclosed in parentheses.
DESCAn optional human-readable description. If a description is provided, then it should be enclosed in single quotation marks.
OBSOLETEAn optional OBSOLETE flag that can be used to indicate whether the DIT content rule is active. If a DIT content rule is marked as OBSOLETE, then it should not be in effect within Oracle Unified Directory.
AUXAn optional list of auxiliary object classes that can be present in entries with the associated structural class. If no values are provided, then such entries are not allowed to have any auxiliary object classes. Values should be specified as one or more of the names or OIDs of the allowed auxiliary classes. If multiple auxiliary classes are allowed, then separate them by spaces and dollar signs, and enclose the entire set of names in parentheses.
MUSTAn optional list of attribute types that are required to be present in entries with the associated structural class. This is in addition to the attribute types required by the object classes included in the entry, and these additional attribute types do not need to be allowed by any of those object classes. Values should be specified as one or more of the names or OIDs of the required attribute types. If multiple attribute types are required, then separate them by spaces and dollar signs, and enclose the entire set of required attribute types in parentheses.
MAYAn optional list of attribute types that can optionally be present in entries with the associated structural class. This is in addition to the attribute types allowed by the object classes included in the entry. Values should be specified as one or more of the names or OIDs of the optional attribute types. If there are multiple optional attribute types, separate them by spaces and dollar signs and enclose the entire set of optional attribute types in parentheses.
NOTAn optional list of attribute types that are prohibited from being present in entries with the associated structural class. This list cannot include any attribute types that are required by the structural class or any of the allowed auxiliary classes, but it can be used to prevent the inclusion of attribute types that would otherwise be allowed by one of those object classes. Values should be specified as one or more of the names or OIDs of the prohibited attribute types. If multiple types are prohibited, then separate them by spaces and dollar signs, and enclose the entire set of prohibited attribute types in parentheses.
An optional set of extensions for the DIT content rule. Oracle Unified Directory currently uses the following extensions for DIT content rules:
X-ORIGIN — Provides information about where the DIT content rule is defined (for example, whether it came from a particular RFC or Internet Draft, or whether it is defined within the project)
X-SCHEMA-FILE — Indicates which schema file contains the DIT content rule definition (This extension is generally used for internal purposes only and is exposed to clients.)
The following provides an example of a DIT content rule description:
( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPersonContentRule' AUX ( posixAccount $ shadowAccount $ authPasswordObject ) MUST uid )
In this case, the numeric OID is 2.16.840.1.113730.3.2.2, which is the OID for the inetOrgPerson structural object class. It has a human-readable name of inetOrgPersonContentRule and no description. It allows entries containing the inetOrgPerson object class to also contain the posixAccount, shadowAccount, and authPasswordObject auxiliary classes, and those entries must contain the uid attribute type. It is not marked OBSOLETE, and it does not define any additional optional or prohibited attribute types, nor does it include any extensions.
At the present time, the mechanism used to handle DIT content rules varies from the LDAPv3 specification. The LDAPv3 specification states that if the structural object class used in an entry does not have a corresponding DIT content rule, then that entry is not allowed to contain any auxiliary object classes. Because Oracle Directory Server Enterprise Edition does not support DIT content rules, Oracle Unified Directory does not prevent the use of auxiliary object classes in entries for which there is no corresponding DIT content rule. If it is desirable to prevent the inclusion of auxiliary classes in a given type of entry, then a DIT content rule should be created with no allowed auxiliary classes to cover entries with the appropriate structural object class.
DIT structure rules can be used to define the allowed hierarchical structure of the directory data. In particular, they make it possible to specify what types of entries are allowed to exist as immediate children of entries with a specified structural object class. For example, only entries with the inetOrgPerson structural class can be immediate children of entries with an organizationalUnit structural object class.
DIT structure rules are themselves hierarchical. Each DIT structure rule is assigned a rule ID, which is an integer value, and is also associated with a name form (which in turn links it to one or more structural object classes). DIT structure rules can also reference one or more superior DIT structure rules, and this provides the mechanism for controlling the data hierarchy. If a DIT structure rule does not specify any superior rules, then entries containing its associated structural object class are allowed to exist at the root of the associated schema. If a DIT structure does specify one or more superior rules, then entries with an associated structural object class are allowed to exist only below entries containing the structural object class of one of those superior rules.
The following sections describe DIT structure rules:
The DIT structure rule description format is described in RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt), section 4.1.7.1, as shown here:
DITStructureRuleDescription = LPAREN WSP ruleid ; rule identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "FORM" SP oid ; NameForm [ SP "SUP" ruleids ] ; superior rules extensions WSP RPAREN ; extensions ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN ) ruleidlist = ruleid *( SP ruleid ) ruleid = number
The DIT structure rule description includes these elements:
The integer rule ID assigned to the DIT structure rule. It must be unique among all other DIT structure rules in the schema.
NAMEAn optional set of human-readable names that can be used to refer to the DIT structure rule. If there is a single name, then it should be enclosed in single quotes. If there are multiple names, then they should each be enclosed in single quotes separated by spaces, and the entire set of names should be enclosed in parentheses.
DESCAn optional human-readable description. If a description is provided, then it should be enclosed in single quotes.
OBSOLETEAn optional OBSOLETE flag that can be used to indicate whether the DIT structure rule is active. If it is marked OBSOLETE, then it should not be taken into account when entries are created or moved.
FORMThe name or OID of the name form with which the DIT structure rule is associated. As mentioned in Section 8.7, "Understanding DIT Structure Rules," the name form associates the DIT structure rule with a structural object class.
SUPAn optional set of superior rule IDs for the DIT structure rule. If there are multiple superior rule IDs, then separate them by spaces, and enclose the entire set of superior rule IDs in parentheses. It is permissible for multiple DIT structure rules to use overlapping sets of superior rule IDs.
An optional set of extensions for the DIT structure rule. Oracle Unified Directory currently uses the following extensions for DIT structure rules:
X-ORIGIN — Provides information about where the DIT structure rule is defined (for example, whether it came from a particular RFC or Internet Draft, or whether it is defined within the project)
X-SCHEMA-FILE — Indicates which schema file contains the DIT structure rule definition (This extension is generally used for internal purposes only and is exposed to clients.)
The following example is the DIT structure rule definition for the uddiContactStructureRule DIT structure rule:
dITStructureRule: ( 2 NAME 'uddiContactStructureRule' FORM uddiContactNameForm SUP ( 1 ) X-ORIGIN 'RFC 4403' )
In this case, the rule ID is 2, and the human-readable name is uddiContactStructureRule. It is associated with the uddiContactNameForm name form (which in turn links it to the uddiContact object class), and it has a superior rule ID of 1. It was defined in RFC 4403 (http://www.ietf.org/rfc/rfc4403.txt). It does not have a description, nor is it marked OBSOLETE.
DIT structure rules can provide a mechanism for placing constraints on Oracle Unified Directory hierarchy, but in order to maximize their utility, it may be necessary to use them in conjunction with support for multiple schemas. For example, consider a directory with a naming context of dc=example,dc=com, below which are two branches: ou=People,dc=example,dc=com and ou=Groups,dc=example,dc=com. If you want to allow only inetOrgPerson entries below the ou=People branch and only groupOfNames entries below the ou=Groups branch, then that can be fully accomplished only if there are different schemas that govern the ou=People and ou=Groups branches.
If there were a single schema governing the entire directory server, then you can imagine that it would have four DIT structure rules:
dITStructureRule: (11 NAME 'domainStructureRule' FORM domainNameForm)
dITStructureRule: (12 NAME 'organizationalUnitStructureRule' FORM organizationalUnitNameForm SUP 11)
dITStructureRule: (13 NAME 'inetOrgPersonStructureRule' FORM inetOrgPersonNameForm SUP 12)
dITStructureRule: (14 NAME 'groupOfNamesStructureRule' FORM groupOfNamesNameForm SUP 12)
This set of DIT structure rules would allow the structure described above, but it would also allow the creation of group entries below the ou=People branch and the creation of user entries below the ou=Groups branch. The only way to prevent that using DIT structure rules would be to define separate schemas for the ou=People and ou=Groups branches and define only the inetOrgPersonStructureRule rule in the schema for the ou=People branch, and only define the groupOfNamesStructureRule rule in the schema for the ou=Groups branch.
Matching rule uses can be used to specify which attribute types can be used in conjunction with a given matching rule when processing a search request with an extensible match filter component. If that extensible match component includes both an attribute type and a matching rule ID, then Oracle Unified Directory checks to see if there is a matching rule use for the associated matching rule, and if there is, it ensures that it allows the specified attribute type to be used with that matching rule.
The matching rule use description format is described in RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt), section 4.1.4, as shown here:
MatchingRuleUseDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "APPLIES" SP oids ; attribute types extensions WSP RPAREN ; extensions
The matching rule use description includes these elements:
The numeric OID of the matching rule with which the matching rule use is associated. There can be only one matching rule use associated with a given matching rule.
NAMEAn optional set of human-readable names that may be used to refer to the matching rule use. If there is a single name, then it should be enclosed in single quotes. If there are multiple names, then they should each be enclosed in single quotes and separated by spaces, and the entire set of names should be enclosed in parentheses.
DESCAn optional human-readable description. If there is a description, then it should be enclosed in single quotes.
OBSOLETEAn optional OBSOLETE flag that can be used to indicate whether the matching rule use is active. If it is marked OBSOLETE, then it should not be taken into account when determining whether to allow an extensible match filter.
APPLIESA set of one or more attribute types that can be used in conjunction with the associated matching rule. If there is an associated attribute type, then its name or OID can be used. If there are multiple attribute types, then separate them by spaces and dollar signs, and enclose the entire set of associated attribute types in parentheses.
An optional set of extensions for the matching rule use. Oracle Unified Directory currently uses the following extensions for matching rule uses:
X-ORIGIN — Provides information about where the matching rule is defined (for example, whether it came from a particular RFC or Internet Draft, or whether it is defined within the project)
X-SCHEMA-FILE — Indicates which schema file contains the matching rule definition (This extension is generally used for internal purposes only and is exposed to clients.)
The following example shows a matching rule use description:
( 1.3.6.1.4.1.26027.1.999.10 NAME 'testAddMRUSuccessful' APPLIES cn )
In this case, the numeric OID is 1.3.6.1.4.1.26027.1.999.10, the single human-readable name is testAddMRUSuccessful, and it can be used in conjunction with the cn attribute. It does not have a description, it is not marked OBSOLETE, and it does not have any extensions.
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|