The two queue managers scenario

An application uses the MQPUT1 call to put messages to queues on queue manager QM1. Some of the messages are then forwarded to queues on QM2, using TCP and LU 6.2 channels. The TCP channels can either use SSL or not. The application could be a batch application or a CICS application, and the messages are put using the MQPMO_SET_ALL_CONTEXT option. This is illustrated in Figure 32.

Figure 32. Example security scenario

The following assumptions are made about the queue managers:

• All the required WebSphere MQ definitions have been predefined or have been made through the CSQINP2 data set processed at queue manager startup.

  If they have not, we need the appropriate access authority to the commands needed to define these objects.

• All the RACF profiles required have been defined and appropriate access authorities have been granted, before the queue manager and channel initiators started.

  If they have not, we need the appropriate authority to issue the RACF commands required to define all the profiles needed and grant the appropriate access authorities to those profiles. You also need the appropriate authority to issue the MQSC security commands to start using the new security profiles.

• All digital certificates required have been created and connected to key rings. The digital certificate sent by QM1 as part of the SSL handshake is recognized by RACF on QM2's system, either because it is also installed in that RACF, or because a matching Certificate Name File (CNF) filter exists.