LDAP only: Multiple Object Classes for a Principal Type

Use

This is only relevant if you are using an LDAP directory server as a data source for your user-related data.

SAP User Management Engine allows you to specify multiple object classes for one principal type. For example, a user object in the LDAP directory can be represented by an object belonging to either the object class inetOrgPerson or myUser.

To specify the object class for a principal type, you have to adjust the configuration file for your data sources. 

Example

In the following example, you have a SUN One directory server and want to configure UME to use a second object class to represent users. The two object classes that represent users are inetOrgPerson and myUser

You have to adjust the private section of your configuration file.

<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.

One restriction is that, using the UME API, you can only create new entries belonging to the first object class in the list. In our example, you can only create entries of the object class inetOrgPerson.

To create a new entry on the directory server, UME needs some additional information, for example that an additional naming attribute is cn. You define this as follows:

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

In the same way, you can specify 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 also have to 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.

In the above example, we described how to define multiple object classes for users and user accounts. In the same way, you can define multiple object classes for groups.

 

The second thing you have to change in the file is the attribute mapping. This is because normally you do not want the logical attributes of the UME API to be 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, you have to add a prefix containing the object class name to every logical and physical attribute name.

You have to adjust the attribute mapping section for the LDAP data source in the configuration file. See also <attributeMapping>.

<attributeMapping>   <principal type="user">     <nameSpaces>       <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>     </nameSpaces>   </principal> </attributeMapping>

You have to specify an attribute mapping for every attribute for which the directory server is responsible and for every object class.