Exit Print View

Sun OpenDS Standard Edition 2.0 Architectural Reference

Get PDF Book Print View

Document Information

The Directory Server Access Control Model

Understanding the Directory Server Schema

Understanding Matching Rules

Matching Rule Description Format

Commonly Used Matching Rules

Value Normalization

Understanding Attribute Syntaxes

The Attribute Syntax Description Format

Commonly Used Attribute Syntaxes

Understanding Attribute Types

Attribute Type Description Format

Attribute Type Inheritance

Attribute Type Implementation

Understanding Object Classes

Object Class Description Format

Object Class Kinds

Object Class Inheritance

Directory Server Object Class Implementation

Understanding Name Forms

Name Form Description Format

Name Form 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

DIT Structure Rule Implementation

Understanding Matching Rule Uses

Matching Rule Use Implementation

Index Databases

Understanding Directory Server Plug-Ins

Directory Server Replication

Root Users and the Privilege Subsystem

Supported Controls and Operations

Value Normalization

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. For example, multiple transformations are often performed for the userPassword attribute type, where values can be encoded using a one-way message digest algorithm, and if that algorithm includes a salt then each time a given value is encoded it can result in a different string. (In fact, this is the intended behavior, which helps prevent dictionary attacks.) In cases like this, the matching rule simply needs to use different logic to determine equality, rather than relying solely on normalization.