Fixes are available
17.0.0.3: WebSphere Application Server Liberty 17.0.0.3
17.0.0.4: WebSphere Application Server Liberty 17.0.0.4
18.0.0.1: WebSphere Application Server Liberty 18.0.0.1
18.0.0.2: WebSphere Application Server Liberty 18.0.0.2
18.0.0.3: WebSphere Application Server Liberty 18.0.0.3
18.0.0.4: WebSphere Application Server Liberty 18.0.0.4
19.0.0.1: WebSphere Application Server Liberty 19.0.0.1
19.0.0.2: WebSphere Application Server Liberty 19.0.0.2
19.0.0.3: WebSphere Application Server Liberty 19.0.0.3
19.0.0.4: WebSphere Application Server Liberty 19.0.0.4
19.0.0.5: WebSphere Application Server Liberty 19.0.0.5
19.0.0.6: WebSphere Application Server Liberty 19.0.0.6
19.0.0.7: WebSphere Application Server Liberty 19.0.0.7
19.0.0.8: WebSphere Application Server Liberty 19.0.0.8
19.0.0.9: WebSphere Application Server Liberty 19.0.0.9
19.0.0.10: WebSphere Application Server Liberty 19.0.0.10
19.0.0.11: WebSphere Application Server Liberty 19.0.0.11
19.0.0.12: WebSphere Application Server Liberty 19.0.0.12
20.0.0.1: WebSphere Application Server Liberty 20.0.0.1
20.0.0.2: WebSphere Application Server Liberty 20.0.0.2
20.0.0.3: WebSphere Application Server Liberty 20.0.0.3
20.0.0.4: WebSphere Application Server Liberty 20.0.0.4
20.0.0.5: WebSphere Application Server Liberty 20.0.0.5
20.0.0.6: WebSphere Application Server Liberty 20.0.0.6
20.0.0.7: WebSphere Application Server Liberty 20.0.0.7
20.0.0.8: WebSphere Application Server Liberty 20.0.0.8
20.0.0.9: WebSphere Application Server Liberty 20.0.0.9
20.0.0.10: WebSphere Application Server Liberty 20.0.0.10
20.0.0.11: WebSphere Application Server Liberty 20.0.0.11
20.0.0.12: WebSphere Application Server Liberty 20.0.0.12
21.0.0.3: WebSphere Application Server Liberty 21.0.0.3
21.0.0.4: WebSphere Application Server Liberty 21.0.0.4
21.0.0.5: WebSphere Application Server Liberty 21.0.0.5
21.0.0.6: WebSphere Application Server Liberty 21.0.0.6
21.0.0.7: WebSphere Application Server Liberty 21.0.0.7
21.0.0.8: WebSphere Application Server Liberty 21.0.0.8
21.0.0.9: WebSphere Application Server Liberty 21.0.0.9
21.0.0.1: WebSphere Application Server Liberty 21.0.0.1
21.0.0.2: WebSphere Application Server Liberty 21.0.0.2
21.0.0.10: WebSphere Application Server Liberty 21.0.0.10
21.0.0.11: WebSphere Application Server Liberty 21.0.0.11
21.0.0.12: WebSphere Application Server Liberty 21.0.0.12
22.0.0.1: WebSphere Application Server Liberty 22.0.0.1
22.0.0.2: WebSphere Application Server Liberty 22.0.0.2
22.0.0.3: WebSphere Application Server Liberty 22.0.0.3
22.0.0.4: WebSphere Application Server Liberty 22.0.0.4
APAR status
Closed as program error.
Error description
Federated Repositories is returning principal name instead of unique name for getUserSecurityName by default, even though the API claims it is returning unique name. Additionally, it is correctly returning security name for all other UserRegistry methods that claim to return security name in their results. Futhermore, is the customer includes the primaryRealm configuration without the userSecurityNameMapping element, it will change the default to be what we claim in the doc. For example: <federatedRepository> <primaryRealm ...> <participatingBaseEntry name="o=mybaseentry"/> <!-- NO USERSECURITYNAMEMAPPING RESULTS IN OSGI DEFAULT OF UNIQUENAME --> </primaryRealm> </federatedRepository>  
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application * * Server Liberty- Virtual Member Manager * * (VMM) * **************************************************************** * PROBLEM DESCRIPTION: Federated Repositories is returning * * "principalName" instead of "uniqueName" * * for getUserSecurityName * **************************************************************** * RECOMMENDATION: * **************************************************************** Federated Repositories is defaulting the userSecurityNameMapping outputProperty to "principalName" instead of the documented default of "uniqueName". This property is used to determine the result returned from the UserRegistry.getSecurityName(String) method. It affects calls made through the UserRegistry API and can be encountered either in the results of direct calls to UserRegisry.getUserSecurityName(String) or in the WSPrincipal returned for authenticated users. It results in these values having short names instead of a distinguished name. It affects the following registries when federated. * LDAP (always federated) * customer CustomRepository implementations SCIM is NOT effected. The correct outputProperty name is used when either of the following is true: 1. the realm configuration is present <federatedRepository> <!-- Realm configuration without explicit userSecurityNameMapping is NOT effected. Default of "uniqueName" will be used. --> <primaryRealm ...> .... </primaryRealm> </federatedRepository> 2. the securityNameMapping outputProperty is explicitly set. <federatedRepository> <primaryRealm ...> .... <!-- Explicitly set mapping is NOT affected. --> <userSecurityNameMapping inputProperty="principalName" outputProperty="uniqueName" /> </primaryRealm> </federatedRepository>
Problem conclusion
The outputProperty for userSecurityNameMapping was changed in the code to default to "uniqueName", which is a distinguished name. The fix for this APAR is currently targeted for inclusion in fix pack 17.0.0.3 Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
Temporary fix
The customer can always override the setting by explicitly setting the userSecurityNameMapping in the federatedRepository configuration. <federatedRepository> <primaryRealm ...> <participatingBaseEntry ... /> .... <userSecurityNameMapping inputProperty="principalName" outputProperty="externalName" /> </primaryRealm> </federatedRepository>
Comments
APAR Information
APAR number
PI87461
Reported component name
WAS LIBERTY COR
Reported component ID
5725L2900
Reported release
CD0
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2017-09-15
Closed date
2017-09-25
Last modified date
2017-09-25
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WAS LIBERTY COR
Fixed component ID
5725L2900
Applicable component levels
RCD0 PSY
UP
Document Information
Modified date:
04 May 2022