JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory 11g Release 1 (11.1.1)
search filter icon
search icon

Document Information

Preface

1.  Introduction

2.  The Directory Server Access Control Model

3.  Understanding the Directory Server Schema

Understanding Matching Rules

Matching Rule Description Format

Commonly Used Matching Rules

Relative Time Matching Rules

Partial Date Or Time Matching Rules

Value Normalization

Understanding Attribute Syntaxes

The Attribute Syntax Description Format

Commonly Used Attribute Syntaxes

The Pattern-Matching Syntax Extension

The Enumeration Syntax Extension

Substitution Syntax Extension

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

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

6.  Directory Server Root Users and the Privilege Subsystem

7.  Supported Controls and Operations

Understanding DIT Structure Rules

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:

DIT Structure Rule Description Format

The DIT structure rule description format is described in RFC 4512, 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:

ruleid

The integer rule ID assigned to the DIT structure rule. It must be unique among all other DIT structure rules in the schema.

NAME

An 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.

DESC

An optional human-readable description. If a description is provided, then it should be enclosed in single quotes.

OBSOLETE

An 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.

FORM

The name or OID of the name form with which the DIT structure rule is associated. As mentioned in Understanding DIT Structure Rules, the name form associates the DIT structure rule with a structural object class.

SUP

An 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.

extensions

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. It does not have a description, nor is it marked OBSOLETE.

DIT Structure Rules and Multiple Schemas

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:

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.