Release 9.0.2
Part Number A95192-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle Internet Directory Administrator's Guide Release 9.0.2 Part Number A95192-01 |
|
This chapter explains attribute uniqueness in Oracle Internet Directory.
This chapter contains these topics:
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. Within a level of a branch of the tree, it was guaranteed to be unique. 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. In short, attribute uniqueness was guaranteed only under a given branch, and only within one level.
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 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:
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:
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.
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.
This section explains requirements for attribute uniqueness
This section contains these topics:
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.
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.
To create an instance of attribute uniqueness across one or more subtrees, the required input information is as follows:
To create an instance of attribute uniqueness across one object class, the required input information is as follows:
You can enable or disable attribute uniqueness.
Use the ldapmodify command-line tool to change the state of the attribute uniqueness policy to be on. If you modify the attribute uniqueness constraint, then you must restart the directory server.
Use the ldapmodify command-line tool to change the state of the attribute uniqueness policy to be off. If you remove the attribute uniqueness constraint, then you must restart the directory server.
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.
Use the ldapdelete command-line tool to delete an attribute uniqueness policy.
As Table 10-2, "Attribute Uniqueness Constraint Entry" illustrates, each attribute uniqueness constraint entry has the following attributes.
All attribute uniqueness constraint entries must be stored under cn=unique, cn=Common, cn=Products, cn=OracleContext.
As Table 10-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.
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.
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.
dn: cn=constraint1, cn=unique, cn=common, cn=products, cn=oraclecontext objectclass: orclUniqueConfig orcluniqueattrname: employeenumber orcluniquesubtree: o=Oracle Corporation, c=US orcleuniqueobjectclass: person
ldapadd -h <host> -p <port> -D <dn> -w <password> -f constraint1.dat
Now, LDAP enforces attribute uniqueness on the employee ID of all US employees at Oracle Corporation.
To remove this constraint do the following:
Regarding replication and attribute uniqueness, when an attribute uniqueness constraint is present in the Oracle Internet Directory replication environment, be very careful about configuring the attribute uniqueness constraints on each server.
All modifications by client applications are performed on the supplier server, therefore, the attribute uniqueness constraint should be enabled on the supplier 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 is likely to cause a performance degradation.
In a multi-master replication scenario, the two masters act both as suppliers and consumers of the same replica. Multi-master 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. Later, when the changes are replicated to the other node, the conflict becomes apparent. You must take this type of conflict resolution into consideration as well. That is, there is a decision to be made about conflict resolution. Should conflict resolution be the replication server's responsibility or not?
|
 Copyright © 1999, 2002 Oracle Corporation. All Rights Reserved. |
|
