Whether you have a single LDAP server or multiple LDAP servers that all Workplace Web Content Management servers access is determined by performance and security considerations.
By default and when security is enabled, each installation of WebSphere Portal allocates to each LDAP user a unique member ID (WMM ID).
Web Content Management references users both by distinguished name and the WMM ID from the server on which the content was originally created. Take care when using multiple LDAP servers so that Web Content Management authentication does not fail when data is syndicated from one server to another.
Two additional scenarios that are not supported by WebSphere Portal but will make Web Content Management security fail include:
- If you have two or more Web Content Management installations using two different LDAP servers, even if these LDAP servers have the same users within
- If you have two or more Web Content Management installations without security enabled that are trying to syndicate between each other
WebSphere Portal expects sharing of a central LDAP repository across installations. However, there are several solutions that can alleviate or remedy these and similar problems.
1. Use the same LDAP database for all environments over which Web Content Management is syndicating.
- Eg. Federate the multiple LDAPs into one
2. Remap the WMM external ID to a unique LDAP attribute on each user record.
- See the Portal InfoCenter topic on mapping external ids in Member Manager for more information
- If you have existing data, then run the MemberFixer after implementing this option
- Note: Some customers set their WMM external ID to the DN, however if the DN contains the name of the user, then this isn't a good idea as if a user leaves and another joins the company with the same name, then the new user will gain access to the old users information. Periodically running the MemberFixer to remove non-existant users (which is already a best practice) will help mitigate this, however its best if the WMM external ID is set to something unique in the first place, say the users 'employee number'.
3. Create another common LDAP tree across all LDAP servers that just contains your WCM groups, then use those groups to set your WCM security
- The LDAP groups must have the same DN and Ext Id across all servers but can contain different members.
- This approach is useful when you must maintain different user groups in different environments under different trees
4. Set up user access on the portal server with virtual groups like All Users, Anonymous, All Authenticated Portal Users.
- For all environments, you can set access on objects using the [All Users] group and anonymous access or any other virtual group because the entry is not stored in the LDAP database. So, if you want to have specific users develop in one Web Content Management installation, but not have access to objects in another installation, you could give access to the virtual group and the security would be retained. If you adopt this solution, you might still want to run the Web Content Management member fixer to clean up the data becuase there will warning messages in the logs. The limitation to this solution is that it only works for virtual users/groups because they are not stored in WMM. Any user/group definition stored in WMM/LDAP will not work.
- In this scenario, you should remove any references to non-virtual groups/users in the security preferences of published Sites / Site Areas, Content, Presentation / Authoring Templates, Taxonomies / Categories and Components, including any non-virtual groups/users set via Workflow Stage security, in the authoring environment, to minimise security errors (and thus maxi
mise performance) during rendering
- Using non-virtual groups/users in the security of non-published items is ok
5. Ensure that all user/groups and their unique IDs are synchronized across all the LDAP servers that are a part of the Web Content Management syndication scenario. One solution is t o export LDAP LDIF files and maintaining LDAP replication across servers.
6. Run the Web Content Management member fixer on the subscriber server at regular intervals or after each syndication event. This solution is not recommended because it introduces a mandatory manual process.
Redbook: Multiple LDAP Directories and WCM
InfoCenter: Configuring WebSphere Portal to use a user registry on Windows
Configure WebSphere Portal V6.1 with LDAP over SSL