Security for the CICS-WebSphere MQ bridge

When you start the CICS®-WebSphere® MQ bridge, you can specify the level of authentication. If requested, the bridge monitor checks the user ID and password extracted from the WebSphere MQ request message before running the CICS program named in the request message.

When you run the CICS-WebSphere MQ bridge monitor transaction (for example, CKBR or your transaction name), you can specify the AUTH parameter to select one of the following levels of authentication:
LOCAL
This level is the default. The bridge monitor starts the bridge task with the CICS default user ID. CICS user programs that the bridge task runs have the authority associated with this user ID. The WebSphere MQ request message cannot request higher authority because any user IDs or passwords in the message are ignored. If the bridge task runs a CICS program that tries to access protected resources, the CICS program might fail.
IDENTIFY
If the message descriptor (MQMD) in the request message specifies a user ID, the bridge monitor starts the bridge task with that user ID. CICS user programs that the bridge task runs have the authority associated with that user ID. The user ID is treated as trusted; that is, the bridge monitor does not authenticate the ID by using password or PassTicket information. If the MQMD does not specify a user ID, the bridge monitor starts the bridge task with the CICS default user ID, in the same way as the LOCAL option.
VERIFY_UOW
The bridge monitor uses the password or PassTicket to authenticate the user ID if all the following conditions apply:
  • The message descriptor (MQMD) in the request message specifies a user ID.
  • The request message includes a WebSphere MQ CICS information header (MQCIH).
  • The Authenticator field in the MQCIH contains a password or PassTicket.
If authentication succeeds, the bridge monitor starts the bridge task with that user ID. If authentication fails, the bridge monitor fails the request with a MQCRC_SECURITY_ERROR return code.

If any one of the conditions listed earlier is not met, the bridge monitor starts the bridge task with the CICS default user ID, in the same way as the LOCAL option. Only the first request message in the unit of work is checked; the bridge ignores user ID and password or PassTicket information in subsequent messages that are part of the same unit of work.

VERIFY_ALL
This level is the same as VERIFY_UOW, except that the bridge task also checks that the user ID is the same in every request message in the same unit of work, and reauthenticates the user ID for each request message, using the password or PassTicket that the message contains.

If you require different levels of authentication for different applications, use multiple bridge monitors with different transaction IDs. You can use CICS surrogate security to restrict the combinations of transaction and user ID that a bridge monitor transaction and user ID can start.

Table 1 shows the user ID under which the bridge monitor is started. The user ID depends on the method that you use to run the bridge monitor transaction, typically CKBR.
Table 1. CICS-WebSphere MQ bridge monitor security
Bridge monitor start method At a signed on terminal User ID for bridge monitor
From a terminal or EXEC CICS LINK in a program Yes Signed-on user ID
From a terminal or EXEC CICS LINK in a program No CICS default user ID
EXEC CICS START with user ID – User ID from START
EXEC CICS START without user ID – User ID from START
The CICS-WebSphere MQ trigger monitor CKTI – User ID from START
The CICS-WebSphere MQ monitor (MQMONITOR) –
  • The MONUSERID attribute of the MQMONITOR resource, if security checking is active for the CICS region (that is, the SEC system initialization parameter is set to YES)
  • User ID that started the MQMONITOR resource, if security checking is disabled for the CICS region (that is, SEC is set to NO)

User IDs and passwords in request messages

When you use the IDENTIFY, VERIFY_UOW, or VERIFY_ALL authentication options, the bridge task and the CICS programs that it runs are started with the user ID that is specified in the message descriptor (MQMD) in the request message. With the VERIFY_UOW and VERIFY_ALL options, the bridge monitor also checks the password specified in the WebSphere MQ CICS information header (MQCIH) in the request message.

To use these levels of authentication, the WebSphere MQ applications must provide a user ID in the MQMD, and they must provide an MQCIH including the password. You must define these user IDs to RACF®. To control the user IDs used, the WebSphere MQ applications must open the request queue for the bridge monitor using open options that include MQOO_SET_IDENTITY_CONTEXT. The applications must also include a value of MQPMO_SET_IDENTITY_CONTEXT in their put message options.

If the bridge monitor finds a problem with the user ID or the password in a request message, it acts as follows:
  • For the IDENTIFY level of authentication, if a message contains a user ID that was revoked, abend AICO might occur. The error reply has return code MQCRC_BRIDGE_ERROR with reason MQFB_CICS_BRIDGE_FAILURE.
  • For the VERIFY_UOW or VERIFY_ALL level of authentication, if the user ID or password is invalid, the request fails with return code MQCRC_SECURITY_ERROR.
  • If a request message omits either the user ID or the password, the bridge monitor runs the bridge task with the LOCAL level of authentication, even if you started the bridge monitor with one of the other authentication options. In that situation, the CICS programs started by the bridge task run with the user ID under which the bridge monitor was started.
You can use a PassTicket in place of a password to avoid the need to flow passwords in messages.
  • The WebSphere MQ application must provide the PassTicket in the MQCIH in the request message.
  • To generate a PassTicket, an application ID is required. The default application ID is the CICS APPLID. You can specify an alternative application ID by using the PASSTKTA parameter when you start the CICS-WebSphere MQ bridge monitor transaction (for example, CKBR or your transaction name).
  • If you use multiple bridge monitors for the same request queue, you must use the PASSTKTA parameter to specify the same application ID for each bridge monitor.
PassTicket validation is performed by using WebSphere MQ services, not EXEC CICS VERIFY, because the CICS service does not allow you to specify an APPLID. For more information about PassTickets, see Generating and using PassTickets for secure sign-on and Setting up security on z/OS in IBM MQ product documentation.

Authority

You must give the following permissions to the user IDs that you use with the CICS-WebSphere MQ bridge. The user IDs include the user ID under which the bridge monitor transaction is started, as listed in Table 1, and any user IDs that WebSphere MQ applications specify in request messages.
  • The user ID under which the bridge monitor transaction is started must have authority to start the CKBP and CKBC transactions for CICS DPL programs, and any alternative transactions that WebSphere MQ applications specify in the TransactionId field in the MQCIH structure in request messages.
  • If WebSphere MQ applications are specifying user IDs in request messages, the user ID under which the bridge monitor transaction is started must be defined to RACF as a surrogate of all the user IDs used in request messages. A surrogate user is one that has the authority to start work on behalf of another user, without knowing the password of the other user. For more information about surrogate user security, see Surrogate user security.
  • The user IDs for the bridge monitor and for all bridge tasks need authority to get messages from the request queue.
  • The user IDs for a bridge task need authority to put messages to its reply-to queue.
  • To ensure that any error replies are received, the user ID under which the bridge monitor transaction is started must have authority to put messages to all reply-to queues.
  • The user IDs for bridge tasks must have authority to put messages to the dead-letter queue.
  • The user ID under which the bridge monitor transaction is started needs authority to put messages to the dead-letter queue, unless you want the bridge to stop if an error occurs.
  • The user IDs for the bridge monitor and for all bridge tasks must have authority to put messages to the backout requeue queue, if one is defined.