PH28253: OIDC RP SHOULD INTERCEPT CALLBACK FROM OP WITHOUT SPECIAL FILTER CONFIG

PH29099: OIDC v1.3.1; OIDC RP: ClassNotFoundException for JsonUtil$DupeKeyDisallowingLinkedHashMap
PH39666: OIDC v1.3.2; OIDC RP: Initial login might fail when the OIDC stateId contains special characters

APAR status

• Closed as program error.

Error description

• When the OpenID Connect (OIDC) Trust Association Interceptor
  (TAI) is configured using a
  provider_(id).interceptedPathFilter, the callback from the
  OpenID provider (OP) is processed automatically and does not
  have to be included in the filter.
  
  If the TAI is configured using a provider_(id).filter, the
  filter must include something to allow the TAI to intercept
  the callback.  For instance:
  
  provider_(id)=request-url^=client1|snoop
  
  To reduce configuration problems, the behavior between the two
  filters should be consistent.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server and OpenID Connect                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: The OIDC TAI provider_(id).filter       *
  *                      property does not automatically         *
  *                      intercept                               *
  *                      the callback from the OP.               *
  ****************************************************************
  * RECOMMENDATION:  Install a fix pack or interim fix that      *
  *                  contains this APAR.                         *
  ****************************************************************
  When the OIDC TAI is configured to intercept requests using the
  provider_(id).filter property, the filter must be constructed in
  a way so that it will intercept the callback from the OP.  This
  should not be necessary.
  For instance, the following configuration will intercept a
  request that contains login_app and redirect the user to the OP
  for login:
  provider_1.identifier=client1
  provider_1.filter=request-url^=login_app
  However, when the OP responds back to the RPs callback URI
  (/oidcclient/client1), the request will not be intercepted and
  the login sequence will fail.
  The administrator must know to add conditions to the filter that
  allow the TAI to intercept the callback from the OP.  For
  instance:
  provider_(id).filter=request-url^=client1|login_app
  

Problem conclusion

• The OIDC TAI is updated so that, when the configuration for a
  provider uses the provider_(id).filter property to intercept
  requests, the callback from the OP will be automatically
  intercepted.
  
  For instance, the following provider config will intercept both
  requests that contain login_app and requests to
  (TAI_CONTEXT_ROOT)/client1:
  
  provider_1.identifier=client1
  provider_1.filter=request-url^=login_app
  
  The fix for this APAR is targeted for inclusion in fix packs
  8.5.5.19 and 9.0.5.6. For more information, see 'Recommended
  Updates for WebSphere Application Server':
  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

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels

• R850 PSY

     UP

• R900 PSY

     UP