With SAP NetWeaver components like SAP Enterprise Portal you will find the User Management Engine (UME) that handles user registry related information. UME can be configured to store common user data to an external LDAP directory. In the past SAP delivered pre-configured XML configuration files for several directories. Since the list of directory servers shipped with EP did not get updated, it does not reflect the current state of supported and certified LDAP directory servers. This is important to know since IBM and other vendors have certified their products for use with UME and SAP Enterprise Portal.
Also SAP have changed the behavior of some values in UME . To avoid conflicts with specific settings, especially with encryption settings, only the attribute mapping and the private section in the XML configuration file should be configured by the customer respectively by the integration consultant. So this weblog is about how to configure UME for use with Tivoli Directory Server as its external user repository.
* IBM Tivoli Directory Server supported and certified by SAP *
IBM Tivoli Directory Server (ITDS), now certified for SAP BC-LDAP-USR 6.30, provides a powerful Lightweight Directory Access Protocol (LDAP) identity infrastructure that is the foundation for deploying comprehensive identity management applications and advanced software architectures like Web services.
The IBM Tivoli Directory Server certification listed on the SAP partner directory:
[http://www.sap.com/softwarepartnerdir/companyname/company.asp?partnerid=22700 | http://www.sap.com/softwarepartnerdir/companyname/company.asp?partnerid=22700]
* IBM Tivoli Directory Server (ITDS)*
ITDS is a powerful, security-rich and standards-compliant enterprise directory for corporate intranets and the Internet. Directory Server is built to serve as the identity data foundation for rapid development and deployment of your Web applications and security and identity management initiatives by including strong management, replication and security features.
see http://www.ibm.com/software/tivoli/products/directory-server/
* General Overview about the SAP Basic Component LDAP interface BC-LDAP-USR 6.30 (UME 4.0) *
SAP UME LDAP specification for BC-LDAP-USR 6.30 describes the general UME LDAP capabilities and requirements like stated below.
Consistent user management requires the integration of the numerous data repositories scattered through the enterprise. SAP User Management Engine (UME) enables you to leverage your existing system infrastructure by accessing user-related data on an existing corporate directory, a database, or an SAP system.
With UME you can connect to an LDAP directory server using an LDAP persistence adapter. You can even read data from and write data to multiple different physical LDAP directory servers, or different branches of the same LDAP directory server.
Entries in an LDAP directory server are organized in a tree-like structure called the Directory Information Tree (DIT). UME supports certain methods of arranging users and groups in a DIT in the LDAP directory server, which are:
You can configure secure connections using the Secure Sockets Layer (SSL) protocol between UME and an LDAP directory server. When SSL is used, the data transferred between the two parties (client and server) is encrypted.
UME also supports data partitioning. This means that you can use different data sources for different user sets or attribute sets. You can partition data in two ways:
User-based data partitioning: Different sets of users are written to different data sources. For example, in a collaboration scenario, where both users internal to your company and users from other companies work together in the same application, the external users need a user account as well. In this case you can configure the persistence manager to store company internal users in the corporate directory, whereas external users are stored in a separate directory. Attribute-based data partitioning: Different sets of attributes are written to different data sources. For example, global user attributes, such as telephone number, email address, and so on, are written to a corporate directory while SAP-specific data is written to a database.
To guarantee interoperability with the SAP software, the external directory product has to be certified for the BC-LDAP-USR 6.30 interface.
How to set up the UME configuration XML (general description of the XML configuration file sections)
In a customer installation, the first step is to identify the scenario that is to be used (e.g. read-only or not) and to extract a default configuration XML for this scenario from the customer’s UME installation.
This default XML contains basic settings for the UME as well as parameters that are specific to the LDAP directory that is used. The certified vendor provides a list of the directory-specific values of these latter parameters that have to be adapted in the configuration XML. The customer enters these values in the XML.
As for the basic settings of the UME, they are independent of the LDAP directory and out of the scope of this description.
XML Configuration Structure
General Structure
Root level
We only consider the section within the <dataSource> tags that correspond to the LDAP directory. The only parts of this section that have to be adapted for the specific LDAP directory are <attributeMapping> and <privateSection>. In the section <responsibleFor>, no changes have to be made for the directory, but it provides information needed for configuring the <attributeMapping> section.
ResponsibleFor Section
This section describes which UME data objects (principal types) will be stored in the LDAP directory. Furthermore it gives the UME attributes of these data objects that will be stored there.
This section will not have to be changed for the LDAP directory, but it provides useful information for <privateSection> and the <attributeMapping> section.
This section has the same structure as the <responsibleFor> section. However, it might contain attributes that were not in the <responsibleFor> section and there is an additional tag + +within the <attribute> tags. The value for the name has to be taken from the list provided by the vendor. If there is no physical attribute for a UME attribute (e.g. because it is not in the section), the value “null” should be used.
Example:
<physicalAttribute name="null"/>
<physicalAttribute name="null"/>
<physicalAttribute name="null"/>
<physicalAttribute name="null"/>
<physicalAttribute name="null"/>
List of possible attributes for the different object types:
* *
* User account: *
| * Attribute * | * Remark * |
j_user | If the same object class is used for user accounts and users, the physical attribute for this should coincide with the one for uniquename . |
j_password | Password of the user account. |
userid | Corresponding user id if different object classes are used for users and user accounts |
certificatehash | |
This attribute has to be mapped to null, as directory servers cannot handle hashed certificates. This prevents the hash value from being stored.
null null javax.servlet.request.X509Certificate | usercertificate |
certificate | usercertificate |
* User: *
* Attribute * | * Value * |
firstname | givenname |
displayname | displayname |
lastname | sn |
fax | facsimiletelephonenumber |
uniquename | uid |
loginid | |
null email | mail |
mobile | mobile |
telephone | telephonenumber |
department | ou |
description | description |
streetaddress | postaladdress |
pobox | postofficebox |
preferredlanguage | preferredlanguage |
PRINCIPAL_RELATION_PARENT_ATTRIBUTE | |
null
* Group: *
* Attribute * | * Value * |
displayName | displayName |
description | description |
uniquename | uniquename |
PRINCIPAL_RELATION_MEMBER_ATTRIBUTE | member |
PRINCIPAL_RELATION_PARENT_ATTRIBUTE | |
null null
Private section
* Attribute * | * Value * |
ume.ldap.access.server_type | IBM-Tivoli |
ume.ldap.access.user_as_account | true |
ume.ldap.access.objectclass.user | inetOrgPerson |
ume.ldap.access.objectclass.uacc | inetOrgPerson |
ume.ldap.access.objectclass.grup | groupofnames |
ume.ldap.access.auxiliary_objectclass.user | |
ume.ldap.access.auxiliary_objectclass.uacc | |
ume.ldap.access.auxiliary_objectclass.grup | |
ume.ldap.access.naming_attribute.user | cn |
ume.ldap.access.auxiliary_naming_attribute.user | uid |
ume.ldap.access.naming_attribute.uacc | cn |
ume.ldap.access.auxiliary_naming_attribute.uacc | uid |
ume.ldap.access.naming_attribute.grup | |
ume.ldap.access.auxiliary_naming_attribute.grup | cn |
ume.ldap.default_group_member.enabled | true |
ume.ldap.default_group_member | cn=DUMMY_MEMBER_FOR_UME |
This configuration has been tested with IBM Tivoli Directory Server v5.2 and SAP Enterprise Portal v6.0 SP10 (UME 4.0).
