PI25203: PROPAGATION LOGIN VIA EXTERNAL LTPATOKEN2 COOKIE DOES NOT CREATE CORRECT SECURITYNAME IN SUBJECT USING CUSTOM LDAPREG

8.5.5.4: WebSphere Application Server V8.5.5 Fix Pack 4
8.5.5.5: WebSphere Application Server V8.5.5 Fix Pack 5
8.5.5.6: WebSphere Application Server V8.5.5 Fix Pack 6
8.5.5.7: WebSphere Application Server V8.5.5 Fix Pack 7
8.5.5.8: WebSphere Application Server V8.5.5 Fix Pack 8
8.5.5.9: WebSphere Application Server V8.5.5 Fix Pack 9
8.5.5.10: WebSphere Application Server V8.5.5 Fix Pack 10
8.5.5.11: WebSphere Application Server V8.5.5 Fix Pack 11
8.5.5.12: WebSphere Application Server V8.5.5 Fix Pack 12
8.5.5.13: WebSphere Application Server V8.5.5 Fix Pack 13
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21

APAR status

• Closed as program error.

Error description

• Propagation Login via externally produced LtpaToken2 cookie
  does not create correct SecurityName in Subject when using
  Custom LdapRegistry in Liberty server.
  The LtpaToken2 cookie only contains the user's DN from LDAP.
  The LDAP is OpenLDAP where the "utorid" attribute is used to
  embody the "userid or uid".
  In WebSphere security terms, this "utorid" is the
  "SecurityName".  Given a properly working and configured
  LdapRegistry the getSecurityName(DN) should return the
  SecurityName value for that DN. .
  Note that the values returned by WSSubject.getCallerSubject()
  should not be the same!
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server Liberty Profile                      *
  ****************************************************************
  * PROBLEM DESCRIPTION: User filter does not consider the       *
  *                      attribute mapping defined for login     *
  *                      attributes                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  While parsing the user filter from the LDAP registry, the
  attribute mapping is not considered when updating the login
  attributes mapping.
  

Problem conclusion

• If user has defined a non-VMM property in the userFilter under
  ldapRegistry configuration and has attribute mapping defined for
  it, meaning has mapped that non-VMM property to any VMM
  property, then that mapping will now be considered now updating
  the login property list which VMM maintains internally and uses
  for the login process.
  
  The fix for this APAR is currently
  targeted for inclusion in fix pack 8.5.5.4.  Please refer to the
  Recommended Updates page for delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

Temporary fix

Comments

APAR Information

• 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

• R855 PSY

     UP