PH51485: OIDC TAI: UPDATE JWK CACHE TO ASSOCIATE WITH DISCOVERED OP

APAR status

• Closed as program error.

Error description

• The OIDC TAI might reject a JWT that was signed by the OP and
  is not past its lifetime due to a signature validation error.
  

Local fix

• You can get around the error by also making your code implement
  the com.ibm.wsspi.security.web.saml.IdentityProviderMapping
  interface.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  IBM WebSphere Application Server            *
  ****************************************************************
  * PROBLEM DESCRIPTION: The OIDC TAI might reject a valid JWT.  *
  ****************************************************************
  * RECOMMENDATION:  Install a fix pack or interim fix that      *
  *                  contains this APAR.                         *
  ****************************************************************
  The OIDC TAI might fail to validate a JWT because the
  signature does not validate successfully.  The kid in the JWT
  is not found in the JWK.
  This issue only occurs when using JWT Authentication.  When you
  use the OIDC RP, the OP always sends an IdToken that contains a
  kid that exists in its JWK file.
  When a request is received with a JWT on the HTTP header, an
  application might have saved, then reused a JWT within its
  lifetime, but beyond the server's key rotation schedule.
  

Problem conclusion

• When the OIDC TAI receives a JWT that has a kid that is not in
  the JWK, the JWT does not validate successfully.
  
  The OIDC TAI alleviates this issue to some degree by
  implementing a JWK cache.  If a kid is not found in the JWK
  cache, the TAI queries the JWK for the keys again and puts them
  in the cache.  The old keys are maintained in the JWK cache for
  a period of time before they're cleared out.
  
  When a server rotates keys, it usually keeps at least one stale
  key in its JWK.  However, if the key rotation is fast enough,
  the kid might fall out of the JWK before a JWT is past its
  lifetime.  This is where the OIDC JWK cache comes in.
  
  If a JWT arrives into the TAI after a key has been removed from
  the JWK, but before it was added to the JWK cache, the JWT fails
  to validate.
  
  Each OIDC provider configuration maintains its own JWK cache.
  
  To increase the number of kid's in the JWK cache, the OIDC TAI
  is updated so when an OP is processed with discovery, the JWK
  cache is associated with the OP object and not the provider
  configuration.  For example, if you have five provider
  configurations that each have the same value for
  provider_(id).discoveryEndpointUrl, instead of five JWK caches,
  you now have one JWK cache.  Any IdToken or JWT that is filtered
  by any of the five provider configurations adds its kid to the
  JWK cache.
  
  Any provider configuration that does not use discovery cannot
  take advantage of this feature even if the
  provider_(id).jwkEndpointUrl values are the same.
  
  The fix for this APAR is targeted for inclusion in fix pack
  8.5.5.25 and 9.0.5.17.
  For more information, see 'Recommended Updates for WebSphere
  Application Server':
  https://www.ibm.com/support/pages/node/715553
  

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

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels