IBM Documentation

link之家

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

相关文章推荐

非常酷的柳树 · 配置数据集 - Tableau· 1 月前 ·

至今单身的茄子 · Asp.Net+Ajax+Access数据库 ...· 3 月前 ·

骑白马的黑框眼镜 · pb 文字转换为二维码 - CSDN文库· 4 月前 ·

文雅的移动电源 · 类型支持，ODBC 日期和时间 - SQL ...· 12 月前 ·

高大的脸盆 · FileReader()读取文件 - 掘金· 1 年前 ·

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

When you run the CICS-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 IBM 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 an IBM MQ CICS information header (MQCIH).
The Authenticator field in the MQCIH contains a password or PassTicket.

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.

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 IBM MQ CICS information header (MQCIH) in the request message.

To use these levels of authentication, the IBM 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 IBM 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 IBM 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-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.

IBM MQ

EXEC CICS VERIFY

Generating and using PassTickets for secure sign-on

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-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 IBM 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 IBM MQ applications specify in the TransactionId field in the MQCIH structure in request messages.
If IBM 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.

Table 1. CICS-MQ bridge monitor security
Bridge monitor start method	At a signed on terminal	User ID for bridge monitor