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
Matching Rule Description Format
Partial Date Or Time Matching Rules
Understanding Attribute Syntaxes
The Attribute Syntax Description Format
Commonly Used Attribute Syntaxes
The Pattern-Matching Syntax Extension
The Enumeration Syntax Extension
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
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, 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:
The 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.
An 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.
An optional human-readable description. If there is a description, then it should be enclosed in single quotation marks.
An 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.
An 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.
An 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.
An 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.
An 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.
An 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.
An 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.
An 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 (Collective Attributes in LDAP) and are one of the types of virtual attributes that are supported in Oracle Unified Directory.
An 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).
An optional usage specification that indicates how the attribute type is to be used. The following attribute usages are allowed:
Used to store user data.
Used to store data required for internal processing within Oracle Unified Directory.
Used to store operational data that must be synchronized across servers in the topology.
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:
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).
Indicates which schema file contains the attribute type definition.
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. 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, 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).