Behavioural changes to MQ client connections introduced by APAR IT25839

Content

The following diagram illustrates the steps taken by a client channel to connect to the queue manager after the fix for APAR IT25839 has been applied.  

The changes introduced by APAR IT25839 are described below:

1. The queue manager no longer checks if a user is blocked by CHLAUTH rules before calling the security exit with reason MQXR_SEC_PARMS.  
   Before this APAR the CHLAUTH blocking rules could take effect and reject a connection attempt before the security exit could take any action.  After this APAR the CHLAUTH blocking rules (step 12 in the diagram) are not checked until after CHLAUTH mapping has been applied (step 8) and the security exit has been called (step 9).  This change ensures that the security exit has the opportunity to act on the mapped user context.  
    
2. The queue manager will attempt to construct an MQCSP before applying CHLAUTH mapping and calling the security exit
   In some circumstances the MQ client will not send an MQCSP structure to the queue manager – for instance if the client pre-dates V8 or is a Java client running in compatibility mode. In this scenario the queue manager will construct the MQCSP from the remote user and password (as long as both are provided).  
   Before this APAR if no MQCSP structure was sent by the client, the queue manager would apply CHLAUTH mapping rules and call the security exit and then (if the exit had not created the MQCSP) the queue manager would create the MQCSP.  After this APAR the queue manager will construct an MQCSP in step 6 (if necessary) before applying CHLAUTH mapping and calling the security exit. This change means that CHLAUTH mapping will apply to the constructed MQCSP before the exit is called, and the result will be passed to the security exit so that the exit can act on the constructed MQCSP and change it if required.
    
3. The queue manager will no longer apply CHLAUTH mapping rules during early channel negotiation.
   Before this APAR if ChlAuthEarlyAdopt=N and a client-side security exit was defined then the queue manager would apply CHLAUTH mapping during channel negotiation (i.e. before step 5 in the diagram when the server-side security exit is invoked with reason MQXR_INIT_SEC / MQXR_SEC_MSG).  However, at this stage of channel start-up the user identity was unknown so the mapping would have been incomplete:- only ADDRESSMAP, SSLPEERMAP and QMGRMAP rules would have been applied.   After this APAR the queue manager will no longer apply CHLAUTH mapping rules during early channel negotiation.  Instead the CHLAUTH mapping rules will be applied during MQCONN processing in step 8 (after the channel negotiation has completed and before the exit is called with reason MQXR_SEC_PARMS).  This simplifies the relationship between channel exits and CHLAUTH mapping and makes it more consistent by guaranteeing that the full set of CHLAUTH mapping rules have been applied when the exit is called with reason MQXR_SEC_PARMS.
    
4. Security exits are no longer called immediately in response to an MQCSP flow sent by an MQ client.
   Before this APAR the execution order of CHLAUTH mapping and security exit (MQXR_SEC_PARMS) invocation depended on whether the client sent an MQCSP flow.  If there was an MQCSP flow then the security exit would get called with reason MQXR_SEC_PARMS before the CHLAUTH mapping.  If there was no MQCSP flow then the CHLAUTH mapping rules would be applied before the security exit was called with reason MQXR_SEC_PARMS.  After this APAR the CHLAUTH mapping will always occur in step 8 before the security exit is invoked with reason MQXR_SEC_PARMS in step 9.  This makes the behaviour consistent regardless of the type of MQ client that is connecting to the queue manager and allows the security exit to act on the mapped user context.