<attributeMapping>
If you are using an LDAP directory as a data source for your user-related data, the ‘logical’ attribute names used by the Java application programming interface (API) of SAP User Management Engine (UME) must be mapped to the ‘physical’ attribute names used in the schema of your corporate LDAP directory.
In the 
preconfigured
files shipped with UME,
the logical attributes of the Java user management API are mapped to the
physical attributes used for the object class inetOrgPerson in the X.500 standard. If you use this standard
without any modifications, you will not need to change the attribute mapping
data. If you have extended this object class in your LDAP directory, or use a
different object class, you can flexibly add additional attributes to the
attribute mapping data or change the attribute mapping data as required. By
providing you with the means to map attributes, UME allows you to use any
schema that suits your company’s requirements.
The following examples illustrate scenarios where you need to change the attribute mapping data:
The logical attribute for a user’s e-mail address used by the user management component is named email, but the physical attribute in the schema for your corporate LDAP directory is named mail. You must map email to mail in the configuration file.
In your company, you wish users to log on with their e-mail address and password instead of with their user ID and password. In a user account, the logical attribute j_user defines the logon ID. By default this attribute is mapped to the unique ID (uid) of a user. By mapping j_user to the physical attribute for the user’s e-mail address, for example mail, users can in future log on with their e-mail address.
For a list of the
set of fixed logical attribute names used in the API, see Logical
Attributes.
Example
<dataSources> ... |
In the above example, the section on the data source CORP_LDAP contains all the configuration data for the LDAP directory.
The section on <responsibleFor>defines which data is stored in the LDAP directory and in particular the logical attributes that are stored in the directory. For each attribute listed here, there must be an entry in the attribute mapping section.
By default the section on <attributeMapping> contains attribute mapping data for the object class inetOrgPerson in the X.500 standard. Here you can modify the physicalAttributename (the attribute name in the LDAP directory) or you can add an additional attribute mapping for attributes outside of inetOrgPerson that you have added to your LDAP schema.
<attribute
name="firstname"> |
Even if the physical and logical attribute name are identical, you should map them. For example, in the above example, displayname maps to displayname.
If an attribute is not mapped, the API will not have access to this data.
Some logical attributes are mapped to "*null*". This means that the API uses this logical attribute, but the logical attribute does not map to a physical attribute. Instead it maps to a computed value.
Ensure that all inetOrgPersons in your LDAP directory contain a valid value for the attribute uid. In the default configuration, this attribute is used to search for users for display in user-management applications such as the role assignment tool.
Alternatively, change the attribute mapping so that uniquename is mapped to cn instead of uid.
<attribute
name="uniquename"> |
In this way, cn is used to search for users for display in user-management applications.
Namespaces
Another useful feature is that you can map logical attributes to different physical attributes depending on the namespace. For example, an application in the namespace com.mycompany.app1might use the physical attribute uid as displayname, whereas another application com.mycompany.app2might use the physical attribute sn as displayname. This would be mapped as follows:
<attributeMapping> |