|
Oracle® Identity Management Integration Guide
10g Release 2 (10.1.2) B14085-02 |
|
 Previous |
 Next |
|
Oracle® Identity Management Integration Guide
10g Release 2 (10.1.2) B14085-02 |
|
|
Previous |
Next |
This section discusses how to configure mapping rules. It contains these topics:
The mapping rules attribute enables you to specify how to convert entries from one directory to another. There are two types of mapping rules: domain rules and attribute rules. You can specify distinguished name mapping and attribute-level mapping. This attribute is assumed to be in the format of a file as described in this section.
Mapping rules are organized in a fixed tabular format, and you must follow that format carefully. Each set of mapping rules appears between a line containing only the word DomainRules and a line containing only the characters ###. The fields within each rule are delimited by a colon (:).
DomainRules srcDomainName1: [dstDomainName1]: [DomainMappingRule1] srcDomainName2: [dstDomainName2]: [DomainMappingRule2] AttributeRules srcAttrName1:[ReqAttrSeq]:[SrcAttrType]:[SrcObjectClass]:[dstAttrName1]: [DstAttrType]:[DstObjectClass]:[AttrMappingRule1] srcAttrName1,srcAttrName2:[ReqAttrSeq]:[SrcAttrType]:[SrcObjectClass]: [dstAttrName2]:[DstAttrType]:[DstObjectClass]:[AttrMappingRule2] ###
where the expansion of each srcAttrName1 and srcAttrName2 would be a single, unwrapped long line.
This section specifies how entries are mapped between Oracle Internet Directory and a connected directory. If the mapping is between Oracle Internet Directory and another LDAP directory, then you can create multiple mapping rules, as explained in "Configuring Mapping Rules". The domain rule specifications appear after a line containing only the keyword DomainRules. Each domain rule is represented with the components, separated by colons, that are described in Table 6-2.
Table 6-2 DomainRule Components
| Component Name | Description |
|---|---|
|
|
Name of the domain or container of interest. Specify NONLDAP for sources other than LDAP and LDIF. |
|
|
Name of the domain of interest in the destination. Specify this component if the container for the entries in the destination directory is different from that in the source directory. If the value assigned to If not specified, this field assumes the value of |
|
|
This rule is used to construct the destination DN from the source domain name, from the attribute given in This field is meaningful only when importing to Oracle Internet Directory, or when exporting to an LDIF file or another external LDAP-compliant directory. Specify this component if any part of an entry's DN in the destination directory is different from that in the source directory entry. This component is optional in LDAP-to-LDIF, LDAP-to-LDAP, or LDIF-to-LDAP. If it is not specified, then the source domain and destination domain names are considered to be the same. |
|
See Also: The mapping file examples at the end of this chapter |
The attribute rule specifications appear after a line containing only the keyword AttributeRules. Attribute rules specify how property values for an entry are related between two LDAP directories. For example, the cn attribute of a user object in one directory can be mapped to the givenname object in another directory. Similarly, the cn attribute of a group object in one directory can be mapped to the displayname attribute in another directory. Each attribute rule is represented with the components, separated by colons, and described in Table 6-3. The attribute rule specifications end with a line containing only the characters ###.
Table 6-3 Components in Attribute Rules
| Component Name | Description |
|---|---|
|
|
For LDAP-compliant directory repositories, this parameter refers to the name of the attribute to be translated. For Oracle Database repositories, it refers to the ColumnName in the table specified by the For other repositories this parameter can be appropriately interpreted. |
|
|
Indicator of whether the source attribute must always be passed to the destination. When entries are synchronized between Oracle Internet Directory and the connected directory, some attributes need to be used as synchronization keys. This field indicates whether the specified attribute is being used as a key. If so, regardless of whether the attribute has changed or not, the value of the attribute is always extracted from the source. A nonzero integer value should be placed in this field if the attribute needs to be always passed on to the other end. |
|
|
This parameter refers to the attribute type—for example, integer, string, binary—that validates the mapping rules. |
|
|
If the source of the shared attribute is an LDAP-compliant directory, then this parameter names the object class to which the attribute belongs. If the source of the shared attribute is an Oracle Database repository, then this parameter refers to the table name and is mandatory. For other repositories, this parameter may be ignored. |
|
|
Optional attribute. If it is not specified, then the For LDAP-compliant directories, this parameter refers to the name of the attribute at the destination. For Oracle Database repositories, it refers to the ColumnName in the table specified by the For other repositories, this parameter can be appropriately interpreted. |
|
|
This parameter refers to the attribute type—for example, integer, string, binary. Note that it is up to you, the administrator, to ensure the compatibility of the source and destination attribute types. Directory Integration and Provisioning does not ensure this compatibility. |
|
|
For LDAP-compliant directories, this parameter refers to the object class to which the attribute belongs, and is optional. For Oracle Database repositories, it refers to the table name, and is mandatory. For other repositories this parameter may be ignored. |
|
|
Optional arithmetic expression with these operators: +, |, and these functions: |
In a newly created synchronization profile, mapping rules are empty. To enter mapping rules, edit a file that strictly follows the correct format.
|
Note: When attributes and object classes are defined in the mapping file, it is assumed that source directories contain the respective attributes and object classes defined in the schema.If a parent container is selected for synchronization, then all its children that match the mapping rules are likewise synchronized. Child containers cannot be selectively ignored for synchronization. |
To create a new mapping file, follow these steps:
Identify the container(s) of interest for synchronization in the source directory.
Identify the destination container or containers to which the objects in the source containers should be mapped to. Be sure that the specified container already exists in the directory.
Determine the rule to create a DN of the entry to be created in the destination directory. In LDAP-to-LDAP, mapping is normally one-to-one. In non-LDAP-to-LDAP, a domain, DN construct rule is required. For instance in the case of synchronizing from a tagged file or Human Resources agent, the mapping rule may be of the form uid=%,dc=mycompany,dc=com. In this case, the uid attribute must be present in all the changes to be applied from Oracle Human Resources. The uid attribute must be specified as a required attribute, as specified in step 6.
Identify the objects that you want to synchronize between directories—that is, the relevant object classes in the source and destination directories. In general, objects that get synchronized between directories include users, groups, organizational units, organizations, and other resources. Identify the actual object classes used in the directories to identify these objects.
Identify the properties of the various objects that you want to synchronize between directories—that is, the attributes in the LDAP context. All the attributes of an object need not be synchronized. The properties of users that you might want to synchronize are cn, sn, uid, mail.
Define the mapping rules. Each mapping rule has this format:
<srcAttrName>:<ReqdFlag>:<srcAttrType>:<SrcObjectClass>: <dstAttrName>:<dstAttrType>:<dstObjectClass>: <Mapping Rule>
While defining the mapping rule, ensure the following:
Every required attribute has a sequence number. For example, if in step 3 the uid attribute is identified as required, then assign a value of 1 in place of <ReqdFlag>.
Every relevant object class has a schema definition on the destination directory.
Every mandatory attribute in a destination object class has a value assigned from the source. This holds good even for standard object classes also, as the different LDAP implementations may not be completely standards-compliant.
It is not necessary to assign all attributes belonging to a source object class to a single destination object class. Different attributes of a source object class can be assigned to different attributes belonging to different destination object classes.
If an attribute has binary values, then specify it as binary in the <attrtype> field.
Mapping rules are flexible: They can include both one-to-many and many-to-one mappings.
One-to-many
One attribute in a connected directory can map to many attributes in Oracle Internet Directory. For example, suppose an attribute in the connected directory is Address:123 Main Street/MyTown, MyState 12345. You can map this attribute in Oracle Internet Directory to both the LDAP attribute homeAddress and the LDAP attribute postalAddress.
Many-to-one
Multiple attributes in a connected directory can map to one attribute in Oracle Internet Directory. For example, suppose that the Oracle Human Resources directory represents Anne Smith by using two attributes: firstname=Anne and lastname=Smith. You can map these two attributes to one attribute in Oracle Internet Directory: cn=Anne Smith. However, in bidirectional synchronization, you cannot then map in reverse. For example, you cannot map cn=Anne Smith to many attributes.
|
See Also: The mapping file examples at the end of this chapter |
The attribute mapping rules supported are:
Concatenation (+): Used to concatenate two string attributes
The mapping rule looks like:
Firstname,lastname: : : : givenname: : inetorgperson: firstname+lastname
For example, if the Firstname is John and LastName is Doe in the source, then this rule results in the givenname attribute in the destination with the value JohnDoe.
OR operator ( | ): Used to assign one of the values of the two string attributes to the destination
The mapping rule looks like this:
Fistname,lastname : : : :givenname: :inetorgperson: firstname | lastname
In this example, givenname is assigned the value of firstname if it exists. If the firstname attribute does not exist, then givenname is assigned the value of lastname. If both the values are empty, then no value is assigned.
bin2b64 ( ): Used to store a binary value of the source directory as a base64 encoded value in the destination directory. Typical usage is as follows:
objectguid: : : :binary: :orclobjectguid: orcladuser:bin2b64(objectguid)
This is required when you need search on the value of (objectguid).
tolower(): Convert the String attribute value to lowercase.
firstname: : : :givenname: :inetorgperson: tolower(firstname)
toupper (): Convert the String attribute value to uppercase.
firstname: : : :givenname: :inetorgperson: toupper(firstname)
trunc(str,char): Truncate the string beginning from the first occurrence of the specified char
mail : : : : uid : : inetorgperson : trunc(mail,'@')
For example, if mail is John.Doe@acme.com in the source, then this rule results in the uid attribute in the destination with the value "John.Doe"
truncl(str, char): Truncate the string up to and including the first occurrence of the specified char
mail : : : : uid : : inetorgperson : truncl(mail,'@')
For example, if mail is John.Doe@acme.com in the source, then this rule results in the uid attribute in the destination with the value acme.com.
trunc(str1, str2): Truncate the string beginning with the first occurrence of the specified string
mail : : : : uid : : inetorgperson : truncl(mail, "@")
dnconvert (str): Used for DN type attributes if domain mapping is used.
This example assumes the following domain mapping rule:
DomainRules cn=srcdomain:cn=dstdomain:
For example:
uniquemember : : : groupofuniquenames : uniquemember : :groupofuniquenames : dnconvert(uniquemember)
In this example, if uniquemember in the source is cn=testuser1,cn=srcdomain, then uniquemember in the destination becomes cn=test user1,cn=dstdomain.
Literals:
Userpassword: : :person: userpassword: :person: 'welcome1'
Based on the preceding discussions, here is a sample mapping file for importing user entries from the Oracle Human Resources database tables by using the tagged-file interface. Note that the source is a non-LDAP directory. This sample file is supplied during installation, at $ORACLE_HOME/ldap/odi/conf/oraclehragent.map.master.
DomainRules NONLDAP:dc=myCompany,dc=com:uid=%dc=myCompany,dc=com AttributeRules firstname: : : :cn: :person email : : : :cn: :person: trunc(email,'@') email : 1 : :uid: :person:trunc(email,'@') firstname,lastname: : : :cn: :person: firstname+","+lastname lastname,firstname: : : :cn: :person: lastname+","+firstname firstname,lastname: : : :sn: :person: lastname | firstname EmployeeNumber: : : :employeenumber: :inetOrgperson EMail: : : :mail: :inetOrgperson TelephoneNumber1: : : :telephonenumber: :person TelephoneNumber2: : : :telephonenumber: :person TelephoneNumber3: : : :telephonenumber: :person Address1: : : :postaladdress: :person state: : : :st: :locality street1: : : :street: :locality zip: : : :postalcode: :locality town_or_city: : : :l: :locality Title: : : :title: :organizationalperson #Sex: : : :sex: :person ###
As described earlier, the mapping file consists of keywords and a set of domain and attribute mapping rule entries. The mapping file in this example contains the domain rule NONLDAP:dc=myCompany,dc=com:cn=%,dc=myCompany,dc=com.
This rule implies that the source domain is NONLDAP—that is, there is no source domain.
The destination domain (:dc=myCompany,dc=com) implies that all the directory entries this profile deals with are in the domain dc=myCompany,dc=com. Be sure that the domain exists before the start of synchronization.
The domain mapping rule (:uid=%,dc=myCompany,dc=com) implies that the data from the source should refer to the entry in the directory with the DN that is constructed using this domain mapping rule. In this case, uid must be one of the destination attributes that should always have a non-null value. If any data corresponding to an entry to be synchronized has a null value, then the mapping engine assumes that the entry is invalid and proceeds to the next entry. To identify the entry correctly in the directory, it is also necessary that uid should be single-valued.
In the case of the tagged file, the source entry does not have any object class to indicate the type of object it is synchronizing. Note that the SrcObjectClass field is empty.
Every object whose destination is Oracle Internet Directory must have an object class. Specify an object class for every attribute.
Note that email is specified as a required attribute in the sample mapping file. This is because the uid attribute is derived from the email attribute. Successful synchronization requires the email attribute to be specified in all changes specified in the tagged file as follows:
Email : 1 : : :uid : : person : trunc(email,'@')
In some cases, the RDN of the DN needs to be constructed by using the name of a multivalued attribute. For example, to construct an entry with the DN of cn=%,l=%,dc=myCompany,dc=com, where cn is a multivalued attribute, the DomainMappingRule can be of this form: rdn,l=%,dc=myCompany,dc=com where rdn is one of the destination attributes having a non-null value. A typical mapping file supporting this could have the following form:
DomainRules NONLDAP:dc=us,dc=myCompany,dc=com:rdn,l=%,dc=us,dc=myCompany,dc=com AttributeRules firstname: : :cn: :person email : : : :cn: :person: trunc(email,'@') email : 1: : :rdn: :person: 'cn='+trunc(email,'@') firstname,lastname: : : :cn: :person: firstname+","+lastname lastname,firstname: : : :cn: :person: lastname+","+firstname firstname,lastname: : : :sn: :person: lastname | firstname EmployeeNumber: : : :employeenumber: :inetOrgperson EMail: : : :mail: :inetOrgperson TelephoneNumber1: : : :telephonenumber: :person TelephoneNumber2: : : :telephonenumber: :person TelephoneNumber3: : : :telephonenumber: :person Address1: : : :postaladdress: :person Address1: : : :postaladdress: :person Address1: : : :postaladdress: :person state: : : :st: :locality street1: : : :street: :locality zip: : : :postalcode: :locality town_or_city: 2 : : :1: :locality Title: : : :title: :organizationalperson #Sex: : : :sex: :person ###
A set of sample integration profiles are created as part of installation by using the Directory Integration and Provisioning Assistant. The properties file used for creating the profile is located in the directory $ORACLE_HOME/ldap/odi/samples.
Sample Import Mapping File
DomainRules dc=mycompany.oid,dc=com:dc=mycompany.iplanet,dc=com AttributeRules # Mapping rules to map the domains and containers o: : :organization: o: :organization ou: : :organizationalUnit: ou: : organizationalUnit dc: : :domain:dc: :domain # Mapping Rules to map users uid : : :person: uid: :inetOrgperson sn: : :person:sn: :person cn: : :person:cn: :person mail: :inetorgperson: mail: :inetorgperson employeenumber: :organizationalPerson: employeenumber: :organizationalperson c: : :country:c: :country l: : :locality: l: :locality telephonenumber: :organizationalPerson: telephonenumber: :organizationalperson userpassword: : :person: userpassword: :person uid: : :person: orcldefaultProfileGroup: :orclUserV2 # Mapping Rules to map groups cn: : :groupofuniquenames:cn: :groupofuniquenames member: : :groupofuniquenames:member: :orclgroup uniquemember: : :groupofuniquenames:uniquemember: :orclgroup owner: : :groupofuniquenames:owner: :orclgroup # userpassword: :base64:userpassword: :binary:
Notice in the preceding example that both the source domain and destination domain are specified in the Domain Mapping rule section. In this example, the source and the destination domains are the same. However, you can specify a different destination domain, provided the container exists in the destination directory.
Also notice in the preceding example that the attribute rules are divided into two sections: user attribute mapping rules and group attribute mapping rules. Specifying the object class in a mapping rule helps to uniquely map a specific attribute of an object.
You can customize mapping rules by adding new ones, modifying existing ones, or deleting some from the mapping rule set specified in the orclodipAttributeMappingRules attribute. In general, to perform any of these operations, you identify the file containing the mapping rules, or store the value of the attribute for a file by using an ldapsearch command as described in the Oracle Internet Directory Administrator's Guide.
You cannot edit the mapping rules in the Oracle Directory Integration and Provisioning Server Administration tool. Instead, mapping rules are stored in a file that you upload to the directory as a value of the attribute. To upload the mapping file, use the Directory Integration and Provisioning Assistant. Once you have created and uploaded the mapping file, you can maintain a copy of it in the $ORACLE_HOME/ldap/odi/conf directory, and upload it again after any future update.
dipassistant mp -profile profile name odip.profile.mapfile=map file
To add a new entry to the mapping rules file, edit this file and add a record to it. To do this:
Identify the connected directory attribute name and the object class that needs to be mapped to Oracle Internet Directory.
Identify the corresponding attribute name in Oracle Internet Directory and the object class to which it needs to be mapped.
Generate the mapping rule elements indicating the conversion that needs to be done on the attribute values.
Load the attribute mapping rule file to the synchronization profile.
For instance, if the e-mail attribute of an entry in the source directory needs to be mapped to the unique identifier of the destination, then it can be:
Email: : : inetorgperson: uid: : person:
After you identify an entry to be modified in the mapping rules file, generate the mapping rule element for the desired conversion of attribute values.
After you identify an entry to be deleted in the mapping rules file, you can either delete the entry from the file or comment it out by putting a hash mark (#) in front of it.
|
See Also:
|
|
Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
|
