IBM® Workplace Web Content Management™ (WCM) content does not render for all users.
The following errors display in the SystemOut.log:
[2/13/08 11:00:33:447 CST] 000001dc WorkspaceMana E Exception
caught while getting workspace ROOTWORKSPACE
javax.jcr.RepositoryException: Failed to login to repository. at com.ibm.workplace.wcm.services.repository.RepositoryServiceUtils.loadWorkspace(RepositoryServiceUtils.java (Compiled Code))
The userID value entered during IBM WebSphere® Portal login does not match the value for the attribute configured for the WP Puma Service parameter, "user.fbadefault.filter".
a. All users have attributes of "uid" and "cn" in the user registry but the attribute values are not necessarily identical.
b. The value of "user.fbadefault.filter" is "cn".
c. The value of the userSecurityNameAttribute is "uid".
d. The value of wmmUserSecurityNameAttr is "uid".
e. Users enter their "uid" value when logging into WebSphere Portal.
user.fbadefault.filter - Defines the default search attribute for users. You can find the value of the
user.fbadefault.filter by opening the WebSphere Application Server Administrative Console and navigating to Resources --> Resource environment providers --> WP PumaService --> Custom properties.
userSecurityNameAttribute - The attribute used by WebSphere Member Manager as the login attribute. The userSecurityNameAttribute is found in the wmm.xml file, located in the <wp_root>/wmm directory (if standalone) or the <WAS_profile_root>/config/wmm directory (if node is federated/managed).
wmmUserSecurityNameAttr - The attribute (only used in case of realm support) used by WebSphere Application Server to look up the user. The wmmUserSecurityNameAttr attribute is found in the security.xml file located in the <WAS_profile_root>/config/cells/<cellname> directory.
Diagnosing the problem
In this particular scenario, the content rendered successfully when the user's uid and cn values in LDAP were identical. However, it would fail when the uid and cn values differed. The reason for this behavior is that Web Content Management takes the login value, calls PUMA to obtain the user.fbadefault.filter value, and searches for <user.fbadefault.filter>="<login value of user>" when it tries to retrieve content for that user.
Therefore, if the LDAP attributes cn and uid have the same value for each user, the content renders successfully. However, if the value of cn ever changes from the value of uid or you have other users that currently do not have identical cn and uid values, the JCR lookup will not work and the content will not render successfully.
When Web Content Management and JCR perform lookups for users, they do not pass an attribute to the API, so the API uses the default (the value specified in the user.fbadefault.filter) as follows:
findByAttribute( user.fbadefault.filter, firstname.lastname@example.org)
However, if the installed version of Web Content Management is at a level that includes APAR PK44051, the PUMA.lookupAttribute is set in the WCMConfigService.properties, and the user is not found by the default lookup, then an additional call will be made by Web Content Management to locate the user:
findByAttribute( puma.lookupAttribute, email@example.com)
Further information is available via the Web Content Management Security MustGather in the section entitled "Security troubleshooting suggestions" at the bottom of the page.
Resolving the problem
Product Support recommends that the following attributes be identical in Web Content Management environments in order to address the issue:
2. userSecurityNameAttribute (when using realm support)
However, if you have a specific reason for having the attribute in #1 be different from the attributes in #2 and #3, Web Content Management can handle this situation if the environment is at a version of Web Content Management (126.96.36.199, 188.8.131.52, 184.108.40.206, or later) that includes APAR PK44051 .
The APAR added code to handle a new attribute, PUMA.lookupAttribute, in <WP_root>/wcm/shared/app/config/wcmservices/WCMConfigService.properties. In the above scenario, you could set the PUMA.lookupAttribute to the login value of "uid" and restart the Portal Server in order to resolve the issue.