Security scenario: two queue managers on z/OS
In this 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/TLS 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 1.
- All the required IBM MQ definitions have been predefined or have been made through the CSQINP2 data set processed at queue manager startup.
If they have not, you 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, you 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/TLS handshake is recognized by RACF on QM2's system, either because it is also installed in that RACF profile, or because a matching Certificate Name File (CNF) filter exists.