| Skip Navigation Links | |
| Exit Print View | |
|
Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory 11g Release 1 (11.1.1) |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory 11g Release 1 (11.1.1) |
2. The Directory Server Access Control Model
3. Understanding the Directory Server Schema
Understanding Attribute Syntaxes
The Attribute Syntax Description Format
Commonly Used Attribute Syntaxes
The Pattern-Matching Syntax Extension
The Enumeration Syntax Extension
Attribute Type Description Format
Object Class Description Format
Directory Server Object Class Implementation
Understanding DIT Content Rules
DIT Content Rule Description Format
DIT Content Rule Implementation
Understanding DIT Structure Rules
DIT Structure Rule Description Format
DIT Structure Rules and Multiple Schemas
Understanding Matching Rule Uses
4. Directory Server Index Databases
5. Directory Server Replication
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, section 4.1.3, in Augmented Backus-Naur Form (ABNF). For more information about ABNF, see RFC 4234 and RFC 5234. 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:
The numeric OID is used to uniquely identify the matching rule in Oracle Unified Directory. Every matching rule must have a unique OID.
The 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.
The 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.
The 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.
The 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 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 (LDAP Syntaxes and Matching Rules), in section 4.2. Some of the most commonly used matching rules include:
These are equality, ordering, and substring matching rules, respectively, that ignore differences in capitalization and also treat multiple consecutive spaces as a single space.
These 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.
These 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.
These 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.
This 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.
This 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 GeneralizedTime 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 GeneralizedTime 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" -w password \ -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.
|