Previous articles on developerWorks have addressed WebSphere MQ security on the distributed platforms. This article examines WebSphere MQ security on z/OS, with particular attention to controlling administrative access, and using RACF classes effectively for MQ security. While this article will be easier to follow for readers with experience with WebSphere MQ for z/OS and RACF, it should be helpful to anyone interested in this topic.


Tom Schneider ( IBM

Photo of Tom SchneiderTom Schneider has worked with WebSphere MQ as an administrator since the product was first released, and has supported products on the z/OS platform for over twenty years. You can contact Tom at

03 June 2009

Make sure that security is enabled

IBM® WebSphere® MQ for z/OS provides many options for security. It lets you define granular security for commands, the resources the commands affect, and application resources accessed through the MQI. However, switches and the RESLEVEL profile are also provided, and they allow security checks to be disabled. Switches and RESLEVEL are not typical RACF constructs, and they are not particularly intuitive. Switches, if defined, disable security checks, while RESLEVEL controls the number of userids to be checked for the userid associated with a WebSphere MQ connection. The first step in configuring a new security setup or reviewing an existing one is to make sure that the security checks that the queue manager's administrators think are enabled, are actually being performed. If switches or RESLEVEL have been defined to bypass some security checks, or to limit the checks done for some userids, make sure that the consequences are understood.


Switches (which are defined in the RACF MQADMIN class) can disable all security checks, or only checks for a particular type of WebSphere MQ resource, such as queues, processes, command resource security, or context. They can apply to a single queue manager, or to all the queue managers in a queue sharing group. Since switches, if they are defined at the queue manager level, turn off security checks, usually the best course of action is not to define any. If switches are implemented, it's important to understand the checks they are disabling, and to make sure that any checks being disabled do not violate local security policies.

When the queue manager starts, the switches in effect are displayed in the JESMSGLG of the queue manager's MSTR address space. These messages can be checked to ensure that the security checks that you expect to be active are indeed active. At many sites, no switches are defined, and all possible checks are done. This is the recommended practice unless there is a good reason to use a switch.

An alternative use for switches is if the queue manager is in a queue sharing group. In that case, combinations of switches can be used to control whether security is implemented at the queue sharing group level, at the queue manager level, or or some combination of the two. Enforcing consistent use of profiles at the queue sharing group or queue manager level can be a good use for switches. But it's also possible to define complex combinations of switches that could make it difficult to tell what profiles are being used to secure a resource. For example, using switches, queue managers in a queue sharing group could be set up so that for some of the queue managers security checks are performed at the queue sharing group level, while for others in the same queue sharing group, security would be implemented at the queue manager level. While there is may sometimes be a reasonable justification for using a set up like this, in general it's better to avoid complex configurations.


In contrast to switches, which are listed when the queue manager starts, there is nothing displayed by the queue manager to show how the RESLEVEL profile has been configured. To make sure this profile and its access list are configured correctly, either the RESLEVEL profile and its access list need to be listed and reviewed, or else it's necessary to infer how it is defined by the checks which are or are not being done.

The hlq.RESLEVEL profile is defined in the MQADMIN class (in WebSphere MQ V7 it can also be defined in the MXADMIN class), and it controls how many userids will be subject to API security checks. RESLEVEL is used by CICS, IMS, batch and TSO jobs, and the Channel Initiator. Batch and TSO jobs can only pass a single userid to the queue manager. CICS, IMS and channels can potentially pass two userids to the queue manager (CICS can pass both the userid for the CICS job, as well as the userid for the individual CICS transaction). Depending on the level of access the userid that makes the connection to the queue manager has to hlq.RESLEVEL, zero, one, or two userids might be checked. If a userid's level of access to RESLEVEL is NONE, the maximum number (either one or two userids) will be checked at the highest levels of access -- CONTROL and ALTER. No userids are checked for API access, so a userid with this level of access is exempt from security for resources accessed through the MQI.

The access level that the userid for the Channel Initiator's started task has to RESLEVEL is the level inherited by all channels, since on z/OS, all channels share the same connection, namely the one opened by the Channel Initiator. If the userid of the Channel Initiator address space has an access level of NONE to RESLEVEL, then two userids (the "channel userid" and the MCAUSER) will be checked for all channels. On the other hand, if the Channel Initiator userid has an access level of CONTROL or ALTER to RESLEVEL, then no userids are checked for MQI access by any channels. Unfortunately, it's easy to misconfigure access to RESLEVEL for the Channel Initiator, with the result that security checks are bypassed for all channels. The recommended practice is to make sure the Channel Initiator's userid has an access level of NONE to RESLEVEL. This will cause two userids to be checked.

An access level of READ to RESLEVEL for the userid of a CICS or IMS job means that only the job userid (and not the transaction userid) will be checked for access. Oddly, for CICS, an access level of UPDATE actually provides a stricter level of security than READ does, since for UPDATE the job userid and the transaction userid, if the transaction has been defined with RESSEC=YES, will be checked. If there is a high level of confidence that the security defined for transactions will prevent them from being executed by unauthorized users, then READ (or UPDATE) access to RESLEVEL for CICS or IMS job's userid might be appropriate.

Some sites grant their administrators CONTROL or ALTER access to RESLEVEL, since they assume that their administrators need access to all queues. Depending on the sensitivity of the data being transported by the queue manager, this assumption is not always a sound one, because on z/OS, WebSphere MQ administrators can define queues without also being granted access to the messages they contain. Also, if administrators have CONTROL or ALTER access to RESLEVEL, then no AUDIT records are created to track access done through the MQI by these users. As most companies want (or are required) to scrutinize activities of privileged users, this practice might not be consistent with local security policies. Finally, it's important to make sure that the Channel Initiator's userid is not added to the Administrators' RACF group, since that will disable MQI security for channels. Connecting the Channel Intiator's userid to the RACF group that was created for administrators, when that group has been granted CONTROL or ALTER access to RESLEVEL, is a common error that essentially turns off MQI security for all channels.

Recommendations for RESLEVEL

  • Define a profile specifically for RESLEVEL, that is, don't allow a generic profile to be the default for RESLEVEL.
  • Define the RESLEVEL profile with UACC(NONE).
  • If transaction security has been configured to prevent unauthorized access, then it might be safe to grant READ access to CICS and IMS job userids (or UPDATE access for CICS job's userid).
  • Except for the CICS and/or IMS job userids, do not grant access to any other userids, and let them pick up the default access level of NONE.
  • The Channel Initiator, batch, and TSO jobs in particular should have an access level of NONE to RESLEVEL.
  • The userid for the Channel Initiator should not be connected to any RACF group that has an access level greater than NONE to RESLEVEL.

If switches or RESLEVEL are being used, don't just undo them!

This article has recommended that you either do not define any switches, or if you do, that they have a clear purpose, such as that all security checks will be done at a queue sharing group level and not at the queue manager level. For RESLEVEL, it is recommended that, with the possible exception of CICS or IMS job userids, no userids are permitted to have any level of access other than NONE to RESLEVEL. Of course, if switches or RESLEVEL as currently defined are not consistent with these recommendations, and are causing security checks to be bypassed, the switch cannot just be deleted, or a userid's access to RESLEVEL cannot be revoked without causing access violations. If you decide to delete switches that are currently defined, a set of profiles for the resources that were not being checked need to be created first, and then the userids or groups that should have access need to be granted an appropriate level of access. If a userid has access to RESLEVEL that is causing it to be exempt for MQI security, profiles must be created to protect WebSphere MQ resources, and the necessary access granted to the userid (or group) that is currently exempt, before access to RESLEVEL can be safely revoked. Failure to create appropriate access lists before deleting switches or revoking RESLEVEL access is likely to cause authorization failures that will lead to outages for applications or channels.

Command security

There are over 100 MQSC commands for WebSphere MQ on z/OS. Unlike the distributed product, there is not a predefined group such as mqm or QMQMADM that automatically has access to all commands. Because access to commands is not automatically granted to one group, it is easier to prevent unauthorized access. At the same time, it complicates set up, because you must decide who (or what) is permitted to issue which commands. While it's possible to use individual profiles for every command, that's probably not a good idea for reasons discussed below.

Users who must issue commands should be divided into several groups or roles, each of which needs access to some commands, depending on how their roles are defined. Once those roles are established, it should be possible to map them to specific sets of commands. If commands can be protected mostly by GENERIC profiles that apply to a set of commands, then there will be fewer access lists to maintain and review. If GENERIC profiles are not used and individual profiles are defined for every command, then many access lists will probably be the same, and a lot of effort will be needed to maintain them and keep them consistent. On the other hand, if individual profiles are defined for each command and the access lists are different for most of them, it means that the roles of users who need access to commands have not been defined clearly. Ideally, a small set of profiles can be defined that map to clear, well-defined roles for the users who need administrative access.

Here are some typical roles, and the access they might require:

Typically have access to all commands.
Security administrators
Need the authority to refresh security.
Need to be able to start and stop the queue manager and channel Initiator, as well as to start and stop channels.
Channel Initiator's userid
Needs the authority to issue any commands in CSQINPX concatenation.
Automation software
Might need some commands such as to start and stop the queue manager.
Monitoring software
Typically needs access to commands to display objects, display status, and possibly commands to start channels and alter queues if the monitor is set up to take action on its own.
Programmers and tech support
Probably need access only to display commands.

The z/OS environment is complex, and can be configured in various ways, so the list above is not definitive, nor are the commands granted to these suggested roles going to be the same from site to site. The point is that organizing users into a few well-defined roles provides a logical way to break down the access they need. Once a logical division of which roles need access to particular commands has been created, an optimal scheme for defining profiles to protect those commands can be found.

Here is one possible arrangement: a GENERIC profile that protects any command not protected by other profiles, a GENERIC profile for DISPLAY commands, and then specific profiles for all other commands. First, define a catch all GENERIC profile that will apply to any command for which a more specific profile has not been defined:

Example 1. Sample GENERIC profile applies to any command that is not protected by a less generic profile

In the sample above, universal access (UACC) is NONE, so by default, no userids have access to the commands protected by this profile. Then the PERMIT command gives ALTER access to MQADMNS, which represents a RACF group that contains only the userids of the queue manager's administrators. This access lets them execute any of the commands protected by this profile. It's useful to define a generic profile like this with UACC(NONE) because it will automatically apply to any new commands that are defined when an upgrade is made to a new release. The RACF statements above would deny access to those new commands to any users except administrators. Obviously that might not be the access that ultimately needs to be defined, but it's a reasonable default.

Similarly, you can use a generic profile to protect all DISPLAY commands. In this case READ access, which allows the commands to be executed, is being granted to everyone. Local security policy may or may not allow display access to be granted universally. Or, it might be best to further subdivide display commands -- for example, splitting the display commands for channels off from the other display commands. Overall though, the DISPLAY commands can be protected with a few GENERIC profiles.

Example 2. Sample GENERIC profile for all DISPLAY commands

Once the profiles above are defined, you can define individual profiles for other commands to allow operators, tech support, monitoring and automation software, and administrators to be permitted to issue them -- for example, commands such as START CHANNEL, SUSPEND QMGR CLUSTER, and so on. In all likelihood, the number of profiles needed to protect these commands should be small, so that only a few well understood access lists need to be maintained. Here are some additional recommendations for command security:

  • Follow the principle of "least privilege" and grant access to commands only to users or groups that have a justifiable need.
  • The Channel Initiator's userid only needs access to commands in CSQINPX, and if the queue manager is in a queue sharing group, to the START and STOP CHANNEL commands. It does not and should not have access to any other commands, especially critical commands like DEFINE, ALTER, and CLEAR.
  • The userid for the CICS and IMS jobs should not need access to any commands.
  • Critical commands, such as ALTER, DEFINE, and DELETE, should usually be accessible only to administrators.

Securing the Channel Initiator and Message channels

For Message channel security on z/OS, three userids must be considered. (In this context, a Message channel is a channel that transports messages between queue managers, as opposed to a client channel.)

  • The userid of the Channel Initiator started task
  • The "channel userid" (also referred to in the WebSphere MQ information as the "network-received" userid)
  • The channel's MCAUSER

How those three userids interact depends on what level of access the Channel Initiator's userid has to RESLEVEL (since it controls whether zero, one, or two userids are checked for access to MQI resources), the setting of the PUTAUT parameter for the channel (since it controls how MCAUSER is evaluated), and the TRPTYPE used by the channel (since the setting for the channel userid depends on the protocol). Additionally, the PUTAUT parameter settings of ONLYMCA and ALTMCA cause the channel userid to be ignored, even if the Channel Initiator's access to RESLEVEL would usually require two userids to be checked.

If the channel initiator's userid has an access level of NONE to RESLEVEL, then usually both the channel and MCAUSER are checked (subject to the PUTAUT setting). If its access to RESLEVEL is READ or UPDATE, then only one userid is checked. Finally, if the channel initiator's access to RESLEVEL is CONTROL or ALTER, no userids are checked for MQI access, so in effect there is no security for channels.

As far as the channel userid, for LU 6.2 receiver channels it is the started task userid of the remote queue manager's Channel Initiator. For TCP/IP channels, it defaults to the local Channel Initiator's userid, since there is no userid associated with the TCP/IP connection. The exception is if SSL is used. SSL lets you set a channel userid for a TCP/IP channel. A channel userid can be associated using the remote channel's certificate at either of these times:

  • When a copy of that certificate is added to the local KEYRING (typically a copy of the certificate will be added only if self-signed certificates are used).
  • Dynamically when the channel is started, using the Certificate Name Filter feature of RACF.

The MCAUSER is the familiar setting from the channel definition. For receiver type channels, it defaults to the Channel Initiator's userid unless it is hard-coded on the channel definition, or is set by a channel security exit.

The rest of this section assumes that the Channel Initiator's userid has an access level of NONE to RESLEVEL, and so both the channel userid and MCAUSER will be checked for MQI access.

Both the channel userid and the MCAUSER default to the userid for the Channel Initiator's started task. Therefore it is important to consider what access rights this userid is granted (and denied). As far as preventing administrative access through Message channels, a good place to start is by denying the Channel Intiator's userid access to set or pass CONTEXT for the SYSTEM.COMMAND.INPUT queue (and any aliases it might have, such as SYSTEM.ADMIN.COMMAND.QUEUE). Since the channel userid and MCAUSER need to be permitted to pass CONTEXT in order to be able to put to a queue, denying them the ability to pass context to SYSTEM.COMMAND.INPUT effectively prevents remote administration, while still letting the local channel initiator put messages on this queue (since it does not need to pass or set context in order to do that). The following two profiles would accomplish this goal:

Example 3. Profiles for CONTEXT of the command queue and its alias

Denying the Channel Initiator's userid access to these profiles prevents any Message channels whose channel userid and/or MCAUSER default to it from being able to issue commands. Of course, if the channel userid or MCAUSER does not default to the channel imitator's userid, then that non-default userid should not have access to alter context on the command queues either.

Important: Going beyond channel security, since any access level higher than NONE allows the user to pass or set context, allows such a userid to alter the UserIdentifier in the Message Descriptor. Essentially, any userid with this access can issue commands using some other user's authority, so there is no justification for any userid to have access greater than NONE to either of these profiles. The one exception might be if monitoring software can issue commands on behalf of users who onto it -- in that case, the userid for the monitor's started task might need to be able to set context on the command queues. If there is such a requirement, it should be listed in the product's documentation.

Securing client channels

Security concerns for MQI channels, that is channels used by WebSphere MQ client programs, center around two issues:

  • If the MCAUSER is not set, it defaults to being the channel intiator's userid.
  • If the MCAUSER is set, it is not required to be authenticated, so whether this userid is trustworthy is open to question.

It's possible for both MQI channels and Java clients to not pass any userid to be the MCAUSER. In that case, MCAUSER defaults to the channel intiator's userid (the same as with Message channels). On z/OS though, defaulting to the channel intiator's userid does not have to allow unauthenticated administrative access (as it does on the distributed platforms), as long as the Channel Initiator's userid is not granted authority to commands it does not require. Recall that the Channel Initiator's userid needs access only to the commands in the CSQINPX concatenation of the Channel Initiator's started task, or, if the queue manager belongs to a queue sharing group, to the START and STOP CHANNEL commands. There is no requirement for any commands to be issued through CSQINPX, so if the queue manager is not part of a queue sharing group, it's possible that the Channel Initiator does not need the authority to issue any commands. Consequently, as far as preventing unauthorized administrative access, the blank MCAUSER issue does not have to present the same exposure on z/OS that it does on distributed platforms.

For clients using SVRCONN channels, the MCAUSER can be set by the client program. For MQI channels, it can be set by passing the logged on userid from the workstation where the client program is executing. For Java clients, any userid can be passed to be the MCAUSER. As noted above, since these userids are not authenticated, there is little reason to trust them. That is, they do not need to be authenticated by the queue manager, or it's operating system, unless some facility is used, such as a channel security exit, which is not supplied as a component of the WebSphere MQ product. So, this issue is not as easily addressed as the blank MCAUSER.

MQI channels pose security concerns that Message channels do not. For one thing, client programs can both get and put messages. Additionally, if the MCAUSER is set for the MQI channel, it is also used to populate the UserIdentifier of the message descriptor. Remember that the UserIdentifier from the MQMD is the userid that is checked to authorize commands passed to the SYSTEM.COMMAND.QUEUE. If someone has discovered the userid of one of the queue manager's administrators (this is not as easy to do on z/OS as it is on distributed platforms, since the administrator is not a predefined userid such as mqm), then if that userid is passed, administrative access can be acquired by an unauthorized person.

How can you address the unauthenticated userid exposure? A hard-coded MCAUSER on the SVRCONN channel can be used to limit the queues (or commands) the channel can access. This technique can be useful for denying access to resources, but is more problematic for granting access, since it indiscriminately gives anyone who can use this channel access whatever resources (such as queues or commands) that the MCAUSER has been granted. Going a step further, SSL with SSLPEER can be used for the SVRCONN channel in combination with a hard-coded MCAUSER. In this case, MCAUSER can control what the channel can access, while SSL and SSLPEER control who can use the channel. Finally, a channel security exit can be used to limit who can use the channel, or to sign on the user, so they are authenticated and then authorized to a limited set of resources. However, since no security exit is provided that can be used on all the main operating systems supported by WebSphere MQ, such an exit will either need to be written in-house, purchased, or downloaded from the Internet.


The z/OS platform is a rich environment that provides many options and the freedom to use those options in a variety of ways, and this characteristic applies to security for WebSphere MQ for z/OS. The goal of this article was not to describe all the RACF classes provided for WebSphere MQ security, or all the options they provide -- that would require a book. Instead this article focused on a few recommendations to ensure that security is active, and to limit administrative access. These recommendations can be used as a foundation on which to build. When implementing any of these recommendations, remember of course to test them first and understand their effects on your current security setup, before you implement them in production.

Summary of recommendations

  • If any switches are defined, make sure that their effect is understood, and is consistent with local security policy.
  • The Channel Intiator's userid, as well as any RACF groups it is connected to, should not have an access level greater than NONE to the MQADMIN class RESLEVEL profile.
  • The authority to issue commands should be granted to only a few well-defined roles. Follow the principle of least privilege, so that access to commands is granted only when a valid need exists.
  • Define profiles in the MQADMIN class to prevent context from being set or passed on the SYSTEM.COMMAND.INPUT queue and any aliases defined for it. Ideally, there should not be any userids, especially the userid of the Channel Initiator, with an access level greater than NONE to these profiles.
  • The userid for the Channel Initiator should not be granted authority to issue commands, except possibly a small set of commands (such as START LISTENER) that are issued through the CSQINPX concatenation of the channel intiator's started task, or the START and STOP CHANNEL commands if the queue manager belongs to a queue sharing group. In particular, the userid for the channel initiator should not have access to commands such as ALTER, DEFINE, and DELETE that can create or modify objects.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=WebSphere MQ for z/OS security