Configuring directory services (LDAP) with WebSphere Commerce
WebSphere Commerce can be configured to use one or more LDAP servers as the master user repository instead of the WebSphere Commerce database. This is typically done when multiple applications need to share a common user repository.
In this configuration, user and organization data in the WebSphere Commerce database is synchronized with data on the LDAP server. When a lookup is done, the data on the LDAP server is considered the master copy, so it will be used to update the WebSphere Commerce database if the LDAP data is more recent than the time of the last synchronization. When a create or update operation is done, the information will be propagated to both the database and the LDAP server. However, a user's password is only stored on the LDAP server.If you currently have users and passwords in the WebSphere Commerce database, and later decide to configure the system with an LDAP server, individual users and their passwords are migrated to the LDAP server during WebSphere Commerce Logon. User passwords cannot be mass exported to the LDAP server because passwords are one-way hashed in the database, so we cannot retrieve the plain text password. During WebSphere Commerce Logon, a check is done to see if the user exists on the LDAP server. If it does not, a check is done to see if the user is in the WebSphere Commerce database. If it is there, authentication is done against the password in the WebSphere Commerce database. If that is successful, the user profile along with the password are pushed to the LDAP server. (The list of attributes that are synchronized with LDAP are specified by ldapentry.xml). On subsequent WebSphere Commerce Logon attempts for that user, since the user profile now exists in the LDAP server, authentication will only take place against the password on the LDAP server.
It is recommended that the organization structure and distinguished names on the LDAP server match what is in WebSphere Commerce database. If the DNs do not match, you must provide an implementation of LDAPIntegrationCmd.java that handles the mapping between the LDAP DNs and the WebSphere Commerce database DNs, by implementing the getCommerceDN() and getLDAPDN() methods. WebSphere Commerce requires the Root Organization (-2001) be the common ancestor of all other organizations, and the Default Organization (-2000) exist directly under the Root Organization.
- OrgAdminConsole: This tool to manage business users and administrators does not list users under the Org -2000 (Default Org), or allow users to be created under the Default Org, since it assumes that is where B2C Shoppers (and guest users) are kept. Accelerator can be used to manage B2C shoppers.
- Access Control: By default, Default Org (-2000) subscribes to GuestShopperManagementPolicyGroup which allows for some administrators (regardless of where they play their role) to manage the users under the Default Org. Guest users are implicitly owned by the Default Organization (-2000), when an access control check is done on this type of user, since guest users do not exist in the MBRREL table.
- MemberRegistrationAttributes.xml: By default, it has configurations that assume the Default Org DN.
- UserRegistrationAdd command: If no parentMember is specified (for example, the B2C scenario), the user will be placed under the Default Org.
To use WebSphere Commerce with LDAP, WebSphere Application Server Administrative Security must be enabled and configured to use Federated Repositories. The Federated Repositories feature is implemented using another WebSphere Application Server component called Virtual Member Manager (VMM). com.ibm.commerce.member.syncbeans.VMMProxy is used by WebSphere Commerce to call VMM APIs to interact with the LDAP server.