This example only applies if you use a directory service as a data source for your user-related data.
Marcus Kopp has a SUN One directory server and wants to configure the UME to use a second object class to represent users. The two object classes that represent users are inetOrgPerson and myUser.
To specify the object class for a principal type, Marcus must modify the following subsections of the directory service section of the data sources configuration file:
Marcus must define the object classes, naming attributes, and auxiliary naming attributes in the <privateSection>subsection of the data source configuration file.
Example: <privateSection> Subsection
The order of the entries in the different tags is very important. The first entry for the object class belongs to the first entry for the naming attribute. In the example, inetOrgPerson, uid and cn belong together. myUser and my_uid belong together.
Using the UME API, Marcus can only create new entries belonging to the first object class in the list. In the example, Marcus can only create entries of the object class inetOrgPerson.
To create a new entry on the directory server, the UME needs additional information, for example that an additional naming attribute is cn. Marcus defines this as follows:
In the same way, Marcus specifies additional object classes.
This tag indicates that if you want to create a new user belonging to the object class inetOrgPerson, you must also specify the super object classes person, organizationalPerson, and top. The auxiliary object classes and naming attributes are only required when a new user is being created. They are not required for searching, modifying, and so on.
The example describes how to define multiple object classes for users and user accounts. In the same way, Marcus can define multiple object classes for groups.
Marcus must change the attribute mapping to prevent the logical attributes of the UME API from being mapped to the same physical attribute name for every object class. In the following example, the firstname attribute is mapped to givenname for the object class inetOrgPerson and to my_givenname for the objectclass myUser.
To distinguish between the object classes, Marcus must add a prefix containing the object class name to every logical and physical attribute name.
Marcus must enter the name of the physical attribute in lower case letters! Otherwise the mapping does not work..
Marcus must adjust the attribute mapping section for the LDAP data source in the configuration file. See also <attributeMapping>.
Example: <attributeMapping> Subsection
Marcus must specify an attribute mapping for every attribute for which the directory server is responsible and for every object class.