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:
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.