Channel security exit programs
You can use security exit programs to verify that the partner at the other end of a channel is genuine. This is known as authentication. To specify that a channel must use a security exit, specify the exit name in the SCYEXIT field of the channel definition.
- SSLPEER (PCF selector MQCACH_SSL_SHORT_PEER_NAME)
- SSLCERTI (PCF selector MQCACH_SSL_CERT_ISSUER_NAME)
- MQCD SSLPeerNamePtr
- MQCXP SSLRemCertIssNamePtr
Existing IBM MQ peer name filters specified via the SSLPEER field of a channel definition are not affected and continue to operate in the same manner as in earlier releases. This is because the IBM MQ peer name matching algorithm has been updated to process existing SSLPEER filters without any need to alter the channel definitions. This change is most likely to affect security exits and applications which depend upon the Subject DN and Issuer DN values returned by the PCF programming interface.
A security exit can be written in C or Java.
- At MCA initiation and termination.
- Immediately after the initial data negotiation is finished on channel startup. The receiver or server end of the channel can initiate a security message exchange with the remote end by providing a message to be delivered to the security exit at the remote end. It might also decline to do so. The exit program is started again to process any security message received from the remote end.
- Immediately after the initial data negotiation is finished on channel startup. The sender or requester end of the channel processes a security message received from the remote end, or initiates a security exchange when the remote end cannot. The exit program is started again to process all subsequent security messages that might be received.
A requester channel never gets called with MQXR_INIT_SEC. The channel notifies the server that it has a security exit program, and the server then has the opportunity to initiate a security exit. If it does not have one, it informs the requester and a zero length flow is returned to the exit program.
- The receiver and sender are each invoked with MQXR_INIT, but these invocations are not correlated and can therefore occur at the same time or at different times.
- The receiver is next invoked with MQXR_INIT_SEC, but returns MQXCC_OK which requires no complementary event at the sender exit.
- The sender is next invoked with MQXR_INIT_SEC. This is not correlated with the invocation of the receiver with MQXR_INIT_SEC. The sender returns MQXCC_SEND_SEC_MSG, which causes a complementary event at the receiver exit.
- The receiver is then invoked with MQXR_SEC_MSG, and returns MQXCC_SEND_SEC_MSG, which causes a complementary event at the sender exit.
- The sender is then invoked with MQXR_SEC_MSG, and returns MQXCC_OK which requires no complementary event at the receiver exit.
The channel security exit program is passed an agent buffer containing the security data, excluding any transmission headers, generated by the security exit. This data can be any suitable data so that either end of the channel is able to perform security validation.
- Security exchange ended with no errors
- Suppress the channel and close down
- The channel security exits typically work in pairs. When you define the appropriate channels, make sure that compatible exit programs are named for both ends of the channel.
- In IBM i , security exit programs
that have been compiled with
Use adopted authority
(USEADPAUT=*YES) can adopt QMQM or QMQMADM authority. Take care that the exit does not use this feature to pose a security risk to your system. - On a TLS channel on which the other end of the channel provides a certificate, the security exit receives the Distinguished Name of the subject of this certificate in the MQCD field accessed by SSLPeerNamePtr and the Distinguished Name of the issuer in the MQCXP field accessed by SSLRemCertIssNamePtr. Uses to which this name can be put are:
- To restrict access over the TLS channel.
- To change MQCD.MCAUserIdentifier based on the name.