<attributeMapping>
If you are using a directory server as a data source for your user-related data, you must map the “logical” attribute names used by the Java application programming interface (API) of the User Management Engine (UME) to the “physical” attribute names used in the schema of your corporate LDAP directory.
In the preconfigured files shipped with the 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 do not need to change the attribute mapping data. If you have extended this object class in your directory service, or use a different object class, you can 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, the UME enables 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 data source configuration file.
In your company, you want users to log on with their e-mail address and password instead of with their logon 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 physicalAttribute name (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 names are identical, you should map them. For example, in the above example, displayname maps to displayname.
An attribute must be mapped, for the API to 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.app1 might 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> |
See also: