9
Attribute Uniqueness

This chapter explains attribute uniqueness in Oracle Internet Directory.

This chapter contains these topics:

• Introduction
• Concepts
• Requirements
• Known Limitations

Introduction

In the prior Oracle Internet Directory architecture, the only way to enforce attribute uniqueness was to make an attribute a part of your DN. This worked well with the user identifier (if used as the RDN), but it was not always appropriate and easy to configure.

Attribute uniqueness was guaranteed only under a given branch, and only within one level. For example, if your DN was uid=dlin, ou=people, o=oracle, then this would be unique directly under ou=people. However, you could have the same user identifier in another branch--for example, uid=dlin, ou=others, o=oracle.

The applications Oracle Internet Directory synchronizes with can use attributes other than DN as their unique keys. The ability of Oracle Internet Directory to enforce attribute uniqueness enables all applications their own notions of "user," to synchronize their user base with a user repository stored in an enterprise's Oracle Internet Directory server.Attribute uniqueness implements the checks that ensure the values of specified attributes are unique each time an entry is modified.

Attribute uniqueness enables the user to define attribute uniqueness across the following:

• The entire directory
• One subtree
• One object class

Concepts

The attribute uniqueness constraint is similar to the pre-operation trigger. This means that the directory server checks all update operations before it performs an LDAP operation. The directory server determines whether the operation applies to an attribute and a suffix (subtree) that you have configured the directory server to monitor.

If an update operation applies to an attribute and suffix monitored by the directory server, and the update operation would cause two entries to have the same attribute value, then the server terminates the operation and returns a constraint violation error to the client.

The directory server performs attribute uniqueness checks on the following:

• A single attribute
• One subtree for each attribute
• One object class

  Note: Attribute uniqueness only works on cataloged attributes.

To check uniqueness of several attributes, you must create a separate instance of the uniqueness constraint for each attribute you want to check.

There are different ways of configuring attribute uniqueness constraint as follows:

• Enable the user to define attribute uniqueness across the entire directory
• Enable the user to define attribute uniqueness across one subtree for each attribute

  For example, Oracle hosts the directories for Company1 and Company2. When you add an entry such as uid=dlin,ou=people,o=Company1,dc=oracle,dc=com, you must enforce uniqueness only in the o=Company1,dc=oracle,dc=com subtree. Do this by listing the DN of the subtree explicitly in the attribute uniqueness constraint configuration.

• Enable the user to define attribute uniqueness across one object class

  For example, ID is a unique attribute on the object class machine, and it is also a unique attribute on the object class person. With the attribute uniqueness enforcement in Oracle Internet Directory, attempting to load two machines with same IDs or two people with same IDs into Oracle Internet Directory returns an attribute uniqueness constraint violation error to the client. A machine ID can have the same value as a person's ID.

Requirements

This section explains requirements for attribute uniqueness

This section contains these topics:

• Creating Attribute Uniqueness
• Enabling and Disabling Attribute Uniqueness
• Specifying the Subtree
• Deleting an Attribute Uniqueness Policy
• Configuration Interface
• Defined Policy Location and Model
• Policy Scoping Rules
• Applying the Attribute Uniqueness Feature

Creating Attribute Uniqueness

To ensure that a particular attribute in your directory always has unique values, you must create an instance of attribute uniqueness for the attribute you want to check. For example, to ensure that every entry in your directory that includes a mail attribute has a unique value for that attribute, you must create an instance of attribute uniqueness associated with mail.

For the same attribute, if there are two different uniqueness policies associated with the attribute and the scope of one policy is a subset of the other scope, then the outermost (or higher level) of the policies take precedence.

Creating Attribute Uniqueness Across an Entire Directory

To create an instance of attribute uniqueness across an entire directory, the required input information is an attribute name for which you want to enforce value uniqueness.

Creating Attribute Uniqueness Across One Subtree

To create an instance of attribute uniqueness across one or more subtrees, the required input information is as follows:

• Attribute name for which you want to enforce value uniqueness
• Subtree locations under which the uniqueness constraint is to be enforced

Creating Attribute Uniqueness Across One Object Class

To create an instance of attribute uniqueness across one object class, the required input information is as follows:

• Attribute name for which you want to enforce value uniqueness
• Object class name

Enabling and Disabling Attribute Uniqueness

You can enable or disable attribute uniqueness.

To enable attribute uniqueness:

1. Use ldapmodify or ldapadd to add the attribute uniqueness constraint.
2. Restart the directory server to enable the policy.

To disable attribute uniqueness:

1. Use ldapmodify or ldapdelete to remove the attribute uniqueness constraint.
2. Restart the ldap server to disable the policy.

Specifying the Subtree

Users can specify the suffix or subtree under which they want the checking to ensure attribute uniqueness by modifying the subtree location attribute in the policy object.

The user can use the ldapmodify command-line tool to import the LDIF file that contains update statements into the directory.

Deleting an Attribute Uniqueness Policy

Use the ldapdelete command-line tool to delete an attribute uniqueness policy.

Configuration Interface

As Table 9-2, " Attribute Uniqueness Constraint Entry" illustrates, each attribute uniqueness constraint entry has the following attributes.

Table 9-1  Attribute Uniqueness Constraint Entry Attributes

Attribute	Description
orcluniqueattrname	The user must specify this attribute.
orcluniquescope	The user has the option to specify this attribute with one of the following values: base onelevel sub If this attribute is not specified, sub is used by default.
orcluniquesubtree	The user can specify the subtree where the attribute uniqueness constraint is enforced. By default, it enforced from the root directory.
orcluniqueobjectclass	The user can specify the object class where the attribute uniqueness constraint is enforced. By default, it is enforced on all object classes.

Defined Policy Location and Model

All attribute uniqueness constraint entries must be stored under cn=unique, cn=Common, cn=Products, cn=OracleContext.

As Table 9-2 illustrates, the default value is applied respectively, when orclunqiuescope, orcluniquesubtree, or orcluniqueobjectclass is not specified in the attribute uniqueness constraint entry. By default, orcluniquescope is subtree, orcluniquesubtree is the entire directory, and orcluniqueobjectclass is all object classes.

Policy Scoping Rules

When multiple attribute uniqueness constraints have different values in orcluniqueattrname, their effects are independent of each other.

When multiple attribute uniqueness constraints have the same values in orcluniqueattrname, but different values in orcluniquesubtree, and their subtrees overlap, the attribute uniqueness constrain with largest subtree scope is in effect.

When multiple attribute uniqueness constraints have the same values in orcluniqueattrname and orcluniquesubtree, but different values in orcluniquescope, the attribute uniqueness constraint with the largest search scope is in effect.

When multiple attribute uniqueness constraints have the same values in orcluniqueattrname, orcluniquesubtree, and orcluniquescope, but different values in orcluniqueobjectclass, then the union of attributes belonging to those object classes is checked.

When multiple attribute uniqueness constraints have the same values in orcluniqueattrname and orcluniqueobjectclass but different values in orcluniquesubtree, and their subtrees overlap, the attribute uniqueness constraint with largest subtree scope is in effect.

When multiple attribute uniqueness constraints have the same values, respectively, in orcluniqueattrname, orcluniquesubtree and, orcluniqueobjectclass, the attribute uniqueness constraint with largest scope is in effect.

Table 9-2  Attribute Uniqueness Constraint Entry

Attribute Name	Must Specify	Valid Value	Default Value	Default Effect
orcluniqueattrname	Yes	Any string	N/A	N/A
orcluniquescope	No	One of the following:	sub
		base		Search base only
		onelevel		Search one level
		sub		Search subtrees
orcluniquesubtree	No	Any string	" "	Entire directory
orcluniqueobjectclass	No	Any string	" "	All object classes

Applying the Attribute Uniqueness Feature

The following example applies the attribute uniqueness feature through Oracle Internet Directory.

Scenario: We want to make sure all employee IDs are unique for all US employees at Oracle Corporation.

Solution: Follow these steps to create and apply an attribute uniqueness constraint.

1. Create an attribute uniqueness constraint entry (in LDIF format) as follows:

   dn: cn=constraint1, cn=unique, cn=common, cn=products, cn=oraclecontext
   objectclass: orclUniqueConfig
   orcluniqueattrname: employeenumber
   orcluniquesubtree: o=Oracle Corporation, c=US
   orcleuniqueobjectclass: person
   
   

2. To apply the attribute uniqueness feature, the attribute uniqueness constraint entries must be loaded using the following:

   ldapadd -h <host> -p <port> -D <dn> -w <password> -f constraint1.dat
   
   

3. Restart the directory server.

Now, LDAP enforces attribute uniqueness on the employee ID of all US employees at Oracle Corporation.

To remove this constraint do the following:

1. Delete the attribute uniqueness entry.
2. Restart the directory server.

Known Limitations

When an attribute uniqueness constraint is present in the Oracle Internet Directory replication environment, be careful about configuring the attribute uniqueness constraints on each server.

Simple Replication Scenario

Because all modifications by client applications are performed on the supplier server, the attribute uniqueness constraint should be enabled on that server. It is not necessary to enable the attribute uniqueness constraint on the consumer server. Enabling the attribute uniqueness constraint on the consumer server does not prevent the Oracle Internet Directory server from operating correctly, but it can cause a performance degradation.

Multimaster Replication Scenario

In a multimaster replication scenario, the two masters act both as suppliers and consumers of the same replica. Multimaster replication uses a loosely consistent replication model. Enabling an attribute uniqueness constraint on one of the servers does not ensure that attribute values are unique across both masters at any given time. Enabling an attribute uniqueness constraint on only one server can cause inconsistencies in the data held on each replica.

The attribute uniqueness constraint must be enabled on both masters. However, there may still be an inconsistent state. For example, in both masters we can successfully modify entries to the same attribute value. However, when the changes are later replicated to the other node, the conflict becomes apparent. You must take this type of conflict resolution into consideration as well, deciding whether conflict resolution should be the replication server's responsibility.