Using security exits on cluster channels

When a cluster-sender channel is first started, it uses attributes defined manually by a system administrator. When the channel is stopped and restarted, it picks up the attributes from the corresponding cluster-receiver channel definition. The original cluster-sender channel definition is overwritten with the new attributes, including the SecurityExit attribute. Note the following:

  1. You must define a security exit on both the cluster-sender end and the cluster-receiver end of a channel, in order for it to be effective. Even though the security exit name is sent over from the cluster-receiver definition, the initial connection must be made with a security-exit handshake.
  2. In addition to the normal security-message handshake, the security exit must validate the PartnerName in the MQCXP structure. The exit must allow the channel to start only if the partner queue manager is authorized.
  3. Design the security exit on the cluster-receiver definition to be receiver initiated. If you design it as sender initiated, an unauthorized queue manager without a security exit can join the cluster because no security checks are performed. Not until the channel is stopped and restarted can the SCYEXIT name be sent over from the cluster-receiver definition and full security checks made. Refer to the WebSphere MQ Intercommunication book for information about sender-initiated and receiver-initiated security exits.
  4. To view the cluster-sender channel definition that is currently in use, use the command:
    DISPLAY CLUSQMGR(queue manager) ALL

    This displays the attributes that have been sent across from the cluster-receiver definition. To view the original definition, use the command:

    DISPLAY CHANNEL(channel name) ALL
  5. If the queue managers are on different platforms, you might need to define a channel auto-definition exit (CHADEXIT) on the cluster-sender queue manager to set the SecurityExit attribute. This is because the format of the exit name in the SecurityExit attribute is different for different platforms. For example, on z/OS(R) the format is SCYEXIT('SECEXIT'), whereas on Windows(R) it is SCYEXIT('C:/path/SECEXIT(function)'). Therefore, although the initial handshake can be accomplished successfully, when the attribute is passed from the cluster-receiver definition on one platform to the cluster-sender definition on another platform, it will have the wrong format. This results in an error saying that the user exit is not valid. To avoid this error, write a channel auto-definition exit to define the correctly-formatted security exit name on the remote queue manager, or design your naming convention for exits to take advantage of the details shown in note 6.
  6. A CHADEXIT may not always be needed on a z/OS queue manager to fix the SCYEXIT value when using an auto-defined CLUSSDRA channel to a z/OS queue manager that is based on that queue manager's CLUSRCVR definition. This is because the queue manager extracts the part of the exit name propagated from a non-z/OS queue manager, to use as the exit name on z/OS. If the extracted part is what you need, for example when the naming convention used for your exits means that it does strip off the correct name, you do not need a CHADEXIT. Distributed exit names are of the form <pathname> libraryname(functionname). If functionname is present, up to 8 chars of that are used. Otherwise, the libraryname, truncated to 8 chars is used. Designing your naming convention for exit to take this into consideration will remove the need for a CHADEXIT.
  7. On z/OS the security-exit load module must be in the data set specified in the CSQXLIB DD statement of the channel-initiator address-space procedure. On Windows the security-exit and channel auto-definition exit DLLs must be in the path specified in the SCYEXIT attribute of the channel definition or the CHADEXIT attribute of the queue manager definition respectively, or in the Registry.