Show TOC

 <attributeMapping>Locate this document in the navigation structure

If you are using a directory service 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 directory service.

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 UMEenables 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:

Tip

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.

Tip

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 more information, see Logical Attributes .

Example

<dataSources>
...
...
<dataSource id="CORP_LDAP"
    className="com.sap.security.core.persistence.datasource.imp.LDAPPersistence"
    isReadonly="false"
    isPrimary="true">
  ...
  <responsibleFor>
    <principal type="account">
    ...
    </principal>
    <principal type="user">
      <nameSpace name="com.sap.security.core.usermanagement">
        <attributes>
          <attribute name="firstname" populateInitially="true"/>
          <attribute name="displayname" populateInitially="true"/>
          <attribute name="lastname" populateInitially="true"/>
          <attribute name="fax"/>
          <attribute name="email"/>
          <attribute name="title"/>
          <attribute name="department"/>
          <attribute name="description"/>
          <attribute name="mobile"/>
          <attribute name="telephone"/>
          <attribute name="streetaddress"/>
          <attribute name="uniquename" populateInitially="true"/>
        </attributes>
      </nameSpace>
      ...
    </principal>
      <principal type="group">
      ...
      </principal>
  </responsibleFor>

  <attributeMapping>
    <principals>
      <principal type="account">
      ...
      </principal>
      <principal type="user">
        <nameSpace name="com.sap.security.core.usermanagement">
          <attributes>
            <attribute name="firstname">
              <physicalAttribute name="givenname"/>
            </attribute>
            <attribute name="displayname">
              <physicalAttribute name="displayname"/>
            </attribute>
            <attribute name="lastname">
              <physicalAttribute name="sn"/>
            </attribute>
            <attribute name="fax">
              <physicalAttribute name="facsimiletelephonenumber"/>
            </attribute>
            <attribute name="uniquename">
              <physicalAttribute name="uid"/>
            </attribute>
            <attribute name="loginid">
              <physicalAttribute name="*null*"/>
            </attribute>
            <attribute name="email">
              <physicalAttribute name="mail"/>
            </attribute>
            <attribute name="mobile">
              <physicalAttribute name="mobile"/>
            </attribute>
            <attribute name="telephone">
              <physicalAttribute name="telephonenumber"/>
            </attribute>
            <attribute name="department">
              <physicalAttribute name="ou"/>
            </attribute>
            <attribute name="description">
              <physicalAttribute name="description"/>
            </attribute>
            <attribute name="streetadress">
              <physicalAttribute name="postaladdress"/>
            </attribute>
            <attribute name="pobox">
              <physicalAttribute name="postofficebox"/>
            </attribute>
          </attributes>
        </nameSpace>
        ...
      </principal>
      <principal type="group">
      ...
      </principal>
    </principals>
  </attributeMapping>

</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">
        <physicalAttribute name="givenname"/>
    </attribute>

Even if the physical and logical attribute name 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.

Note

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">
        <physicalAttribute name="cn"/>
    </attribute>

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.app2 might use the physical attribute sn as displayname . This would be mapped as follows:

 <attributeMapping>
    <principals>
      <principal type="user">
        <nameSpace name="com.mycompany.app1">
          <attributes>
            <attribute name="displayname">
              <physicalAttribute name="uid"/>
            </attribute>
          </attributes>
        </nameSpace>
        <nameSpace name="com.mycompany.app2">
          <attributes>
            <attribute name="displayname">
              <physicalAttribute name="sn"/>
            </attribute>
          </attributes>
        </nameSpace>
        ...
      </principal>
    </principals>
  </attributeMapping>

 

Considerations for Attribute Mapping

When the UME is configured for a LDAP directory as the data source, not all attributes are stored in the LDAP by default. Some attributes are stored in the database of the AS Java. This presents you, the system administrator, with a problem. Since this data is stored in individual systems you must keep the data synchronized across all these systems. The following table lists the options for mapping attributes.

Options for Mapping Attributes

Option Advantage Disadvantage

Leave the attributes in the individual systems

You do not have to configure anything else.

You cannot manage the data centrally. This is OK if you do not have too many systems. The more systems you have, the more work is required to keep the data synchronized.

Map the properties to an existing attribute

You can manage the attribute centrally in the LDAP.

The data format of the attribute must match for every system that reads the data. All systems that write to this attribute must write in the correct format.

The AS Java supports a locale, which consists of the ISO 639-1 language code and an optional ISO 3166 country code separated by an underscore ( _ ). If you map this attribute to a preferred language attribute in the LDAP, this attribute must use this format. If another system writes English to the LDAP preferred language attribute, the AS Java cannot interpret this value, because it does not conform to the required data format.

For more information, see Customizing a UME Data Source Configuration .

Extend the LDAP schema

You can manage the attribute centrally in the LDAP.

Extending the LDAP schema requires you to implement a development project to create new physical attributes in your LDAP and then map them to the logical attributes of the AS Java. You must also support this custom development. The same also applies to making sure the data format of the attributes remains consistent for all systems as described above. For more information about how to extend your LDAP schema, refer to the documentation of your LDAP vendor.

 

The following is a list of significant attributes or groups of attributes, which are stored in the database of the AS Java:

  • Time zone and locale
  • Accessibility level
  • Address attributes
  • Security policy attributes

Time Zone and Locale

The Java-based attributes time zone and locale do not always have a suitable physical attribute in the LDAP directory. The LDAP directory may not support the format used by the AS Java or there may not even exist at all. If you do not keep these attributes consistent across systems, it can lead to undesired behavior, such as, a user is configured for one language or time zone in a front-end system and another language or time zone in a back-end system. This can result in the user receiving an e-mail from the back-end system in a language, which the user does not understand, or in a different timezone that might be confusing.

Accessibility Level

This attribute alerts SAP applications to users who require extra audio support for screen readers, for example. All systems that deploy SAP applications need this attribute to support users with special needs.

For more information, see the Accessibility documentation.

Address Attributes

According to the inetOrgPerson standard all address data is included in the streetaddress attribute. If you use your LDAP as a read-only data source, this data is all stored in the streetaddress attribute. If you use your LDAP as a read-write data source, when you write to the LDAP only the data in the streetaddress attribute is written to the LDAP. The other address attributes, such as city and zip are written to the database of the AS Java. You need to be aware of where the AS Java writes this data, especially if other systems are dependent on this information.

Tip

If you enable self-management in a system with write-access to your LDAP, your users might remove the city and postal code from their street address and enter them in the city and zip attributes. This makes the streetaddress attribute in the LDAP less useful for other systems.

Security Policy Attributes

When you use an LDAP directory for password management, it is desirable to have attributes such as lastpasswordchange, validto, and passwordhistory managed centrally. Unfortunately LDAP directories use proprietary or unsupported data formats to store this information. Every LDAP vendor handles this properties differently. SAPdoes not supply any mappings to security policy attributes and instead writes this data to the database of the AS Java. You must maintain this data decentrally.

For more information, see Security Policy .