Example: Multiple Object Classes for a Principal Type

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

<privateSection>     <ume.ldap.access.server_type>SUN</ume.ldap.access.server_type>     …     <ume.ldap.access.objectclass.user>         inetOrgPerson,myUser     </ume.ldap.access.objectclass.user>     <ume.ldap.access.objectclass.uacc>         inetOrgPerson,myUser     </ume.ldap.access.objectclass.uacc>     …     <ume.ldap.access.naming_attribute.user>         uid,my_uid     </ume.ldap.access.naming_attribute.user>     <ume.ldap.access.auxiliary_naming_attribute.user>         cn     </ume.ldap.access.auxiliary_naming_attribute.user>     <ume.ldap.access.naming_attribute.uacc>         uid,my_uid     </ume.ldap.access.naming_attribute.uacc>     <ume.ldap.access.auxiliary_naming_attribute.uacc>         cn     </ume.ldap.access.auxiliary_naming_attribute.uacc>     … </privateSection>

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 UMEneeds additional information, for example that an additional naming attribute is cn . Marcus defines this as follows:

    <ume.ldap.access.auxiliary_naming_attribute.user>         cn     </ume.ldap.access.auxiliary_naming_attribute.user>

In the same way, Marcus specifies additional object classes.

    <ume.ldap.access.auxiliary_objectclass.user>         person,organizationalPerson,top     </ume.ldap.access.auxiliary_objectclass.user>

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.

<attributeMapping> Subsection

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 adjust the attribute mapping section for the LDAP data source in the configuration file. See also <attributeMapping> .

Example: <attributeMapping> Subsection

<attributeMapping>   <principal type="user">     <nameSpace name="com.sap.security.core.usermanagement">       <attributes>          <attribute name="inetorgperson:firstname">           <physicalAttribute name="inetorgperson:givenname"/>         </attribute>         <attribute name="myuser:firstname">           <physicalAttribute name="myuser:my_givenname"/>         </attribute>         <attribute name="inetorgperson:displayname">           <physicalAttribute name="inetorgperson:displayname"/>         </attribute>         <attribute name="myuser:displayname">           <physicalAttribute name="myuser:my_displayname"/>         </attribute>         <attribute name="inetorgperson:lastname">           <physicalAttribute name="inetorgperson:sn"/>         </attribute>         <attribute name="myuser:lastname">           <physicalAttribute name="myuser:my_sn"/>         </attribute>       </attributes>     </nameSpace>   </principal> </attributeMapping>
 

Marcus must specify an attribute mapping for every attribute for which the directory server is responsible and for every object class.