How to troubleshoot :Users do not have access to syndicated content

Problem:
After syndicating between two or more Web Content Management (WCM) instances, on the subscriber instance users do not have access to the newly syndicated content. In the security section of the content items, the users appear to have been given access; however, the content is still not accessible to these users in the new environment. In some cases you may no longer see the Author/Owner fields populated or see the user security even defined in the object anymore.
The issue is the way WebSphere Portal, or more specifically WMM (WebSphere Member Manager), expects these users to be managed. Essentially, security in Portal is expected to be shared throughout all Portal environments, that is, all portal instances refer to the same LDAP server. In a true production cluster, this is the way things would be configured. Each instance of Portal allocates each LDAP user a unique Member ID when security is enabled. Web Content Management references users both by distinguished name and WMM ID. So WCM content items will have a reference to the WMM ID from the server that the content was originally created on. Because of this, there are several scenarios where the user security will fail:


1. If you have two or more WCM instances pointing to two different LDAP servers, even if these LDAP servers have the same users within
2. If you have two or more WCM instances without security enabled trying to syndicate between each other


So, in the above two scenarios, content in the delivery cluster cannot find the specified LDAP users, even though they exist in both LDAP servers or non-LDAP environments. When a user logs into the delivery environment, that user cannot see content even though he uses the same username as in the authoring environment because WCM is using both the distinguished name and the WMM ID to find content for that user.
A typical symptom are errors like the following in both the WCM and Portal logs:


14:34:0.719 Servlet.Engine.Transports : 6 com.presence.connect.wmmcomms.PrincipalInformation warn The Member: uid=wpsadmin, o=default organization Could not be found in the User Repository. Reason: Message: EJPSG0002E: Requested Member does not exist.{0}, Cause: com.ibm.portal.puma.MemberNotFoundException: EJPSG0002E: Requested Member does not exist.{0}



Answer
It must be noted that the above two configurations are neither expected nor supported by WebSphere Portal. As mentioned, Portal expects sharing of a central LDAP repository across instances. However, there are several solutions that may alleviate or remedy this problem.
Possible Solutions:

1. Remap the WMM External ID to an LDAP attribute; you use distinguished name or some unique attribute as the unique identifier. Then when syndicate, you can then change the attribute as needed. Whatever attribute is chosen, must be unique.

To do so, follow the Portal Information Center topic "Mapping external IDs (extId) in Member Manager" about how to do this mapping:

http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/wmm_map.html

2. Have the same user/groups and unique IDs across any and all LDAPs that are a part of the WCM syndication scenario. This can be achieved by Option 1 above or by possibly exporting LDAP ldif files and/or maintaining some kind of LDAP replication across servers.

3. Apply all the latest WCM Member Fixer fixes and run the WCM Member Fixer at regular intervals or after every syndication.

4. Set up user access on the server with WCM/WPS virtual groups like All Users, Anonymous, All Authenticated Portal Users. What this means is that for all environments, the customer can set access on objects using the [All Users] group and Anonymous access or any other virtual group as the entry is not stored in WMM / LDAP. So, if you want to have user A, B and C develop in one WCM instance, but not have access to objects in the second instance, you could give access to the virtual group and then the security would be retained. If you adopt this solution, you may still want to run the WCM Member Fixer to clean up the data as you will see a lot of warning in the logs. The limitation to this solution is that it will ONLY work for Virtual Users/Groups as these are not stored in WMM. Any user/group definition stored in WMM/LDAP will not work.

5. Leave the security different across all WCM server instances. In this scenario, you would then update your data set for whatever level of user access you desire in each environment. You will then need to manually update the WCM objects for proper security.

6. Use the same LDAP for all environments that WCM is syndicating over.

There may be other solutions that have not been mentioned which might work for other scenarios.