Getting started with WebSphere MQ for z/OS security


Typically on z/OS, RACF administrators define the security profiles used by IBM® WebSphere® MQ. However, they may have only limited knowledge of WebSphere MQ, and therefore an incomplete understanding of the effect of the profiles that they define. MQ administrators may also lack a thorough understanding of the security settings, since they are not defining them. This article provides an introduction to security for WebSphere MQ on z/OS. It does not assume any previous knowledge of the topic. It gives you an overview of the facilities to secure WebSphere MQ, along with guidance on how to apply those facilities to secure your queue managers. The article is designed for both audiences: RACF administrators (and others) who are familiar with z/OS but not WebSphere MQ, and MQ administrators who are familiar with WebSphere MQ, but not with how to secure it on z/OS.

I've written two previous developerWorks articles about WebSphere MQ security, and this article refers to them rather than repeating information that they contain:

This article describes security implemented with RACF. If your system uses a different security manager, the syntax for the security settings will be different, but the general information should still apply.

WebSphere MQ basics

This section describes the types of resources that are used by WebSphere MQ and that you want to protect. It is included for readers with a z/OS background who are not familiar with WebSphere MQ. If you are already familiar with WebSphere MQ, you may want to skip to the next section, WebSphere MQ resources and the RACF classes that protect them.

Enable users to interact with the queue manager. In some cases an individual user connects to the queue manager, or in other cases a job, such as a CICS region or the channel initiator, establishes the connection.
Can be entered through the system console, an ISPF interface, a batch utility program, or through program calls to define resources, and to control the queue manager.
Contain messages. The ability to route and store messages is, of course, the reason for using WebSphere MQ.
Queue context
Consists of fields in the message header such as UserIdentifier. The header on messages is known in WebSphere MQ as the message descriptor.
Alternate userid
A surrogate userid. It allows one userid to be authorized to use a different userid for authorization when accessing a resource such as a queue or topic.
A new type of resource introduced in WebSphere MQ V7. Topics support publish/subscribe, a messaging model that allows one-to-many, or many-to-one messaging in addition to the point-to-point (one-to-one) messaging model that queues implement.
Define a job or transaction which can be triggered to consume one or more messages. Triggering provides a way to automatically start a batch job, CICS or IMS transaction, or a channel to process messages as they arrive on a queue.
Provide a list of resources used by WebSphere MQ.

The RACF classes described in this article directly control access to the resources listed above. In addition to them, here are two other WebSphere MQ resources you need to know about:

Queue manager
Executes on z/OS as two started tasks: a master address space and a channel initiator. It provides support for messages, and for routing those messages to applications or other queue managers.
Define communication routes between queue managers, or from a WebSphere MQ client to a queue manager.

The application programming interface (API) for WebSphere MQ is called the message queue interface (MQI).

WebSphere MQ resources and the RACF classes that protect them

RACF controls access by using rules, called profiles, that are defined in classes. A RACF class contains profiles that apply to a specific type of resource. For example, the MQQUEUE class contains profiles that control access to queues. WebSphere MQ V7.0.0 added support for classes that can contain profiles using mixed case. If mixed case profiles are used, only the part of the profile that represents the resource itself can be in mixed case. For an example of a mixed case profile, see Example 8 below. The following table lists the classes defined for WebSphere MQ, and the type of resource that each class protects. The third and fifth columns of the table list the group classes. A group profile can protect a set of resources with names that cannot easily be protected by a generic profile, because a group profile includes a list of resources (such as a list of fully qualified queue names), but collects them all under a single profile so that an access list can be applied to the group. The MQCMDS and MQCONN classes do not have related group or mixed case classes, and MXTOPIC does not have related upper case classes.

Table 1: Resources and the RACF classes that protect them
Type of resource protectedUpper case classUpper case group classMixed case class (v7 and later)Mixed case group class (v7 and later)
Topic (v7 and later)MXTOPICGMXTOPIC

In the remainder of this article, when the non-group upper case class such as MQQUEUE is mentioned, it will represent any of the classes from the same row of Table 1. For example, when the article lists MQQUEUE, profiles in GMQQUEUE, MXQUEUE or GMXQUEUE could also be used.

Most resources map to a specific set of classes; for example the MQQUEUE, GMQQUEUE, MXQUEUE, and GMXQUEUE classes protect queues. The profiles in MQADMIN and its related group and mixed case classes apply to several different types of resources. These are switches and the RESLEVEL profile, as well as MQI security for Alternate User and Context, and finally command resource security. There is more detail about all of these later in this article.


WebSphere MQ V7.0.0 or later has a new QMGR parameter named SCYCASE. You can set it to UPPER (the default) or MIXED to control whether the queue manager will use upper or mixed case RACF classes. As the table above shows, some classes such as MQCMDS and MQCONN are available only in upper case, while others like MXTOPIC and GMXTOPIC are available only in mixed case. Classes that have only an upper or mixed case version (such as MQCMDS or MXTOPIC) are available for both SCYCASE UPPER or MIXED. The classes that have both an upper and mixed case version (such as MQQUEUE and MXQUEUE), are available only in one form or the other, as determined by the setting of SCYCASE.

More about RACF profiles

All profiles for WebSphere MQ begin with an hlq, which is either the name of the queue manager, or if the queue manager is a member of a queue sharing group, it can be the name of the queue sharing group. Most of the examples in this article use a queue manager name of CSQ1 for the hlq on the sample profiles.

If you are unfamiliar with RACF, profiles include a universal access setting. The UACC parameter specifies universal access and defines the default access level for users or groups that are not in the access list of the profile and have not been explicitly granted an access level. The OAM used by WebSphere MQ on distributed platforms implements generic profiles differently from how RACF implements generic profiles, due in part to the effect of the UACC. For more information on UACC, generic profiles, and the levels of access (NONE, READ, UPDATE, CONTROL and ALTER) that RACF uses, see the article Comparing WebSphere MQ security on distributed platforms and z/OS. If you are familiar with security for WebSphere MQ on distributed platforms as implemented by the OAM but are unfamiliar with security on z/OS using RACF, that article should help you to understand this article.

MQADMIN class profiles that control security

There are two types of profiles in the MQADMIN class that control how security is implemented:

Switch profiles
Control if security is enabled or disabled, and alternatively, if the queue manager is part of a queue sharing group, whether or not security is implemented at the queue manager or queue sharing group level.
RESLEVEL profiles
Control the number of userids that are subject to authorization for any resources accessed through a connection.


Switches are optional -- you do not have to define any. Switches can be used for two different purposes:

  • Switches can disable particular security checks, or turn off all security for the entire queue manager.
  • If the queue manager is a member of a queue sharing group, then switches can control whether security will be implemented at the queue manager or queue sharing group level.

Here are examples of switches that disable security. The first switch, if defined, would disable security for queue manager CSQ1:

Example 1. switch to disable all security for a queue manager.

This switch, if defined, would deactivate command resource security checks for queue manager CSQ1:

Example 2. switch to disable resource security checks.

If you are already using switches, or if you are planning to use them, make sure you understand the effect that they will have. If switches disable some type of security, what effect will that have on the security of the queue manager overall? As an example, if commands are left unprotected, then queues cannot be secure because if anyone can define a QALIAS, they can use the QALIAS to bypass queue security. For an explanation of how an alias queue can be used to bypass other security controls, see Special considerations for alias queues below.

For queue managers in a queue sharing group (QSG), switches can be used to control whether security checks will be done at the queue manager level, QSG level, or both. (A queue sharing group is a set of queue managers on z/OS that can store messages in a coupling facility rather than in pagesets. An application that is connected to a queue manager in a QSG can put messages to a shared queue, and then an application connected to any of the queue managers in the QSG can get the messages.) If a set of queue managers in a QSG are supposed to be "clones" of one another, then configuring security at the QSG level can be useful because it will cause all the queue managers in the QSG to use the same set of profiles.

If you are using switches and need further guidance, there is a wealth of detailed information under Switch profiles in the WebSphere MQ V7 information center.


There will only be one RESLEVEL profile for the queue manager. The level of access that the userid connecting to the queue manager (that is, the userid that issued the MQCONN command) has to the RESLEVEL profile determines how many userids will be checked for MQI access through that connection. For example, for CICS, the access that the CICS region userid has to RESLEVEL determines if one, two, or even no userids will be checked for access to WebSphere MQ resources. If the CICS region has an access level of NONE, then two userids are checked: the CICS job userid and the CICS transaction userid. If either userid does not have the required authorization to open the resource, then access fails. If the CICS region has an access level of READ to RESLEVEL, then only one userid will be checked -- the CICS region userid.

For any type of connection to the queue manager (the next section is about connection security), an access level of CONTROL or ALTER means that no userids are checked for MQI access to the queue manager's resources, such as queues, topics, and so on. So access to RESLEVEL can be classified in two ways:

  • Access of NONE, READ or UPDATE means that at least one userid (possibly two depending on the access level) will be checked for MQI access to WebSphere MQ objects.
  • Access of CONTROL or ALTER, on the other hand, means that there is no MQI security for that connection. A setting like this, which exempts a connection from security, should be used with great caution, or not at all.

For more information about RESLEVEL, see the article WebSphere MQ for z/OS security, and the topic "Using the RESLEVEL security profile" in the WebSphere MQ V7 information center, which includes tables that show the effect of different access levels to RESLEVEL for the various connection types such as CICS, IMS, and batch.

Controlling connections to the queue manager

The profiles in the MQCONN class control which userids have authorization to connect to the queue manager. A user must connect to the queue manager to be able to get or put messages, to issue commands such those that define or alter queues, start channels, and so on. Connecting is similar to logging on, except that the user does not need to provide a userid and password to connect, because WebSphere MQ typically uses an identity that was already established. For example, for the CSQOREXX ISPF interface, WebSphere MQ uses the identity that the user established when logging onto TSO. Separate profiles control access from different environments on z/OS, such as CICS, IMS, batch, DB2 stored procedures, and so on. Here are the four profiles that can be defined in the MQCONN class:

  • hlq.BATCH controls access from batch jobs, TSO applications, DB2 stored procedures, and Unix System Services (USS).
  • hlq.CHIN applies to access by the channel initiator.
  • hlq.CICS controls access from a CICS address space.
  • hlq.IMS is checked for access from IMS control and application processing regions.

For the some connections, such as the channel initiator or CICS, only the region itself needs authorization to connect to the queue manager. For example, for the channel initiator, the connection established by the channel initiator is used by it and by all of the channels. For a CICS region, the connection established by the CICS region is used by any transactions running in that region.

Command security

The MQCMDS class protects the MQSC commands used to administer WebSphere MQ. MQSC commands fit into three basic groups:

  • DISPLAY commands.
  • DEFINE, DELETE, ALTER commands: these create, delete or modify WebSphere MQ resources such as queues, topics, channels, and so on.
  • All other commands: these include commands to start and stop the queue manager, start and stop channels, refresh security, and so on.

There are over 100 different commands, so you need to organize them so that the profiles that protect them are as straightforward as possible. Determining the roles at your site that require access to WebSphere MQ commands, and then implementing role-based security can provide a way to group the commands. The article WebSphere MQ for z/OS security contains extensive discussion about potential roles in a z/OS shop, and how you might define generic profiles to protect commands with a relatively small set of profiles. Usually, it is fairly easy to decide which roles need access to DISPLAY, DEFINE, DELETE, and ALTER commands, but it might take more planning to determine which roles need access to the other commands.

Special considerations for alias queues

A QALIAS object can define an alias for a queue, or in WebSphere MQ V7.0 or later, an alias for a topic. When the QALIAS is defined, there is no resource security check for the target of the alias. For example, userid ROBERT1 issues this command to define alias queue APP1.ALIAS:

Example 3. Command to define an alias queue

But there is no check on whether or not ROBERT1 can define or access the target of the alias, queue PAYROLL.QLOCAL. Furthermore, when a program opens the alias queue, the userid that opens the alias only needs to have access to the QALIAS itself; the userid does not need any access to the target of the alias if the target is a queue. Therefore the authority to define a QALIAS can allow a user to bypass security, and only the most trusted administrators should be permitted to define or alter a QALIAS. If the QALIAS names a topic as its target (rather than a queue), then the user opening the QALIAS must have access to not only the alias queue, but also the topic.

Command resource security

Command resource security provides a secondary level of checking for commands. First, the user must have access to the command through the MQCMDS class. Assuming the user has the authority to issue the command, then command resource security is checked to see if the user has the authorization to issue the command against the specific resource named by the command. Command resource security profiles are defined in the MQADMIN class. Profiles start with the queue manager name (or the QSG name), then name the type of object (such as QUEUE or TOPIC), and finally end with a fully qualified or generic resource name:

Example 4. Command resource security profile for APP1 queues

The command in the sample defines a profile for queue manager CSQ1, to protect queues that begin with APP1. So, for a user to define a queue that began with APP1, the user needs authorization to the command to define the queue, as well as ALTER access to the MQADMIN class CSQ1.QUEUE.APP1.** profile.

MQI security

This section describes security for the WebSphere MQ application programming interface, which is called the MQI. These are the profiles that control what can or cannot be done through the MQI. The MQI allows a program to get or put messages as well as inquire on and modify queues. The MQI can also allow a program to manipulate context for queues, specify alternate userids, publish or subscribe to topics, and inquire on processes and namelists.

Queue security

Profiles in the MQQUEUE class control access to queues. Four levels of access are meaningful for MQQUEUE:

  • NONE does not allow any access.
  • READ allows the user to browse messages or to MQINQ (inquire) on attributes of the queue.
  • UPDATE allows the user to get or put messages. It does not allow get and put access to be granted independently of each other. The user also gets the access permitted by READ. (QALIASes can be used to separate the authority to get or put messages -- there is more information on this topic below.)
  • ALTER allows the user to MQSET (modify) some attributes of the queue. The user also gets the access rights provided by UPDATE.

If you are familiar with the OAM and security for distributed WebSphere MQ, you may wonder why RACF defines access levels such as READ and UPDATE, rather than levels such as INQUIRE, GET, PUT and so on. RACF uses NONE, READ, UPDATE, CONTROL, and ALTER as access levels for all classes, not just those defined for WebSphere MQ. So for WebSphere MQ, one of the predefined levels of access in RACF controls access to particular MQI actions. For more discussion of RACF access levels versus OAM permissions, see Comparing WebSphere MQ security on distributed platforms and z/OS.

Security for queue context

A message descriptor (that is, a messages header) is at the start of every WebSphere MQ message, and it includes a set of fields called message context. There are two sets of context information: identity context identifies the user who first put the message on a queue and includes fields such as the UserIdentifier, while origin context shows the application that put the message on the queue where it is currently stored and includes PutDate, PutTime ,and other fields. Profiles in the MQADMIN class control whether the user executing an application can pass or set context. Here is an example of the command to define a profile that would protect context for any queue defined to queue manager CSQ1 that begins with MYAPP2:

Example 5. Profile to protect CONTEXT for MQAPP2. queues.

If CONTROL access is granted to a group, such as AP2USRS, it would allow users in that group to set both origin and identity context:

Example 6. PERMIT command to grant access to a CONTEXT profile.

Special considerations for CONTEXT security for the command queue

Context security has a special significance for the queue used for command input, SYSTEM.COMMAND.INPUT, and any aliases defined for it. The queue manager checks the userid in the identity context for authorization when a command is put to the SYSTEM.COMMAND.INPUT. Therefore any user that has the authority to pass or set identity context on SYSTEM.COMMAND.INPUT or its alias can, potentially, issue a command with some other userid's authority. For this reason, in most circumstances, no users should have the authority to pass or set context for SYSTEM.COMMAND.INPUT and any aliases defined for it. (One exception is if the queue manager is in a QSG. In that case, the SND userid for an IGQ connection, or the channel or MCAUSER, might need CONTROL access.)

Alternate user security

Alternate user authority can allow the current userid to open and use a WebSphere MQ object with an alternate userid. For example, a server application might browse a message from a queue, copy the userid in the message descriptor to use as its alternate userid, and then open the queue for destructive gets with that alternate userid. The current task or transaction userid needs UPDATE access to the alternate user profile that protects the alternate userid, in order to be authorized to use it. Profiles in the MQADMIN class protect alternate user authority. This example defines a profile to protect AP1USER as an alternate userid, and then the PERMIT command authorizes MQMON to use AP1USER as an alternate userid:

Example 7. Commands to define and grant access for alternate user security

Topic security

Topics support the publish/subscribe capabilities introduced in WebSphere MQ V7 and are arranged in topic trees. A topic tree can contain any number of nodes, each of which are related to topic strings. Administrative TOPIC objects can be defined that match a particular topic string. The TOPIC object provides default settings for the topic string that matches it, as well as topics under it in the topic tree that do not have a TOPIC object defined to match them. In addition to providing default settings, TOPIC objects can have a RACF profile defined for them to implement topic security. Here is an example of a small topic tree that represents a few musical instruments:

Figure 1. Topic tree of a few musical instruments
sample topic tree
sample topic tree

This topic tree is composed of these topic strings:

Table 2: Topic strings from the musical instrument topic tree
topic string

The topic strings are not required to have a TOPIC object defined for them, but suppose that you have defined the following TOPIC objects: Instruments, Winds, and Winds.Flute. Furthermore, when you defined the TOPIC objects, they were mapped to the topic strings shown above in Table 2. Note that there is no TOPIC object for Instruments/Winds/Clarinet:

Table 3: TOPIC objects and their topic strings
TOPIC objecttopic string

To implement security, profiles can be defined in the MXTOPIC class to match the TOPIC objects. The connection between the name of the TOPIC object and the topic itself is the TOPICSTR parameter of the TOPIC object. TOPICSTR, for example, Instruments/Winds/Flute from Table 2, can be up to 10,240 characters, but the TOPIC object name is limited to just 48 characters. So the name of the TOPIC objects is arbitrary; the TOPIC object for TOPICSTR Instruments/Winds/Flute could be any of these: INSTRUMENTS.WINDS.FLUTE, Winds.Flute, Flute, and so on. What is important for your site is that you choose TOPIC names that are meaningful within the context of the topic trees that you will define.

The background information about topic strings and TOPIC objects is necessary to be able to discuss topic security, because it has some characteristics that make it different from the security on other WebSphere MQ objects such as queues. One difference is that profiles in the MXTOPIC class contain a qualifier for PUBLISH or SUBSCRIBE, so the authorization to publish or subscribe to a topic can be granted independently. (This is different from queue security on z/OS, where the same profile protects the ability to both get and put, and there is therefore no way to grant one without the other unless you use QALIASes.) Security for topics also has this characteristic: if a user has authority to a TOPIC object, then that user implicitly has the same authority to any topics that occur below the TOPICSTR for that TOPIC object within the topic tree. For example:

Example 8. Define a profile for subscribing to a topic, and grant access to a RACF group

The PERMIT command lets users in RACF group WSUSERS subscribe to the TOPICSTR associated with the Winds TOPIC object, as well as any topic strings that occur below it in the topic tree. WSUSERS can subscribe to topics under the topic string Instruments/Winds even if TOPIC objects and RACF profiles have been defined for those topic strings and WSUSERS does not have the necessary level of access to those topics. This example could lead to a situation where WSUSERS has ALTER access to the MXTOPIC profile CSQ1.SUBSCRIBE.Winds and has an access level of NONE to profile CSQ1.SUBSCRIBE.Winds.Flute, but WSUSERS can still subscribe to Instruments/Winds/Flute. This behavior for topic security runs counter to the usual behavior of RACF profiles, where the profile that is the best match applies. In the end, for situations where implicit access is being granted to a TOPIC object associated with a topic string lower in the topic tree, it might be better to just explicitly grant access, rather than allow the implicit access to apply. For example, in the case just described, grant WSUSERS ALTER access to profile CSQ1.SUBSCRIBE.Winds.Flute, which will make the access that WSUSERS has obvious to anyone reviewing the access lists for the profiles, and will avoid RACF messages due to users in group WSUSERS that have implicit access, but do not have explicitly granted access.

You cannot determine the effect of MXTOPIC profiles on topic security just by reviewing the profiles themselves. That is, the effect of your MXTOPIC profiles must be understood within the context of the topology of your topic trees and the TOPIC objects that you have defined. For additional information, see the topic "Publish/subscribe security" in the WebSphere MQ V7 information center .

Process and namelist security

"The MQPROC and MQNLIST classes provide process and namelist security. These classes are similar in that there are only two meaningful levels of access to them:

  • NONE does not permit any access.
  • READ permits the user to open the process or namelist for inquiry (MQINQ) from a program.

Processes and namelists provide information. A process defines the application to start when a message arrives on a queue. A namelist defines a list of resources, such as the list of clusters that a queue manager is a member of. Therefore all a program needs to be able to do through the MQI is to view the information in the process or namelist. That is why the control provided through the MQPROC and MQNLIST classes is limited to controlling which users can inquire on these resources programmatically. Profiles in the MQCMDS class control the ability to define, delete, alter, or display a process or namelist using MQSC commands, or some other command interface.

Using the WebSphere MQ RACF classes to secure a queue manager

So far we've looked at the RACF classes that are available to secure WebSphere MQ, and have examined the objects that they can protect. The next topic is how profiles in these classes can be defined to protect a queue manager and its resources. The RACF classes provide many options and capabilities. The biggest challenge in securing the queue manager may be planning how security will be implemented, and defining a set of profiles that are organized well enough to be easily understood, while still providing the necessary security. The rest of this article will suggest some ways to accomplish that.

Switch and RESLEVEL profiles

Switch and RESLEVEL profiles do not directly secure WebSphere MQ resources, but rather control how other security profiles are applied. If security is being set up for a new queue manager, then it is probably best not to define any switches that disable security. On the other hand, if you are evaluating the security set up for an existing queue manager, and if switches were defined that disable security, then you need to review what security checks are being bypassed. If the rationale was documented for defining the switches, you can review it to see if the justification for the switches still applies. It could be that a security setup that was acceptable several years ago when the queue manager was first defined is no longer consistent with your site security policy.

If switch profiles have been defined to enforce security at a queue sharing group level (rather than to disable security) then you need to check that these profiles work as expected. If the switches are causing some profiles (such as queue manager level profiles) to be ignored, then it is probably best to delete those unused profiles so that they do not cause confusion if someone lists and reviews the profiles for the queue manager.

For the RESLEVEL profile, a profile should be defined for the queue manager (or queue sharing group) so that some unexpected generic profile does not apply. The UACC for the profile should be NONE. If any users or groups are in the access list, make sure you understand why that access was granted. Finally, any users or groups that have CONTROL or ALTER access to RESLEVEL are exempt from MQI security, so if any users have this level of access, you need to question why they have it, and then possibly revoke it.

The switches (if any exist) and the access list for RESLVEL should be similar throughout all of your queue managers. That is, the same settings used in production should be used in test -- at least test and production should be similar if you want to be able to test your security configuration in a test environment, rather than testing it in production.

Profiles other than Switches and RESLEVEL profiles

The RACF profiles other than switches and RESLEVEL directly control access to the queue manager, the queue manager's resources, and the WebSphere MQ commands that are used to maintain the queue manager. One way to consider these resources is to separate the ones that provide the product's infrastructure from the resources that you have defined locally. Examples of the first category are the MQSC commands, as well as SYSTEM objects such as the various SYSTEM queues that the queue manager defines the first time it starts up. The second category, resources that you define locally, includes things like application queues, channels, and topics.

Some aspects of WebSphere MQ security are simpler than others, such as connection security as implemented by the MQCONN class. While connection security is important, there are not a lot of decisions to be made about it. Connection security is a simple binary setting: either a user can connect to the queue manager, or they cannot. Security for namelists and processes is similarly straightforward: the MQNLIST and MQPROC classes have only two meaningful settings, NONE or READ.

Backstop profiles

Before considering profiles for SYSTEM and application resources, this section describes backstop profiles, which provide a baseline setting for the class. RACF defines the classes used for WebSphere MQ so that if no profile is found, then the default is no access (that is, DFTRETC=8 in their class descriptor table definitions). Even though the default is to deny access, it is a common practice to define a backstop profile such as CSQ1.** in the MQQUEUE class. Typically, you define a backstop profile with UACC(NONE), and no or very few users in the access list. A backstop profile will be used if no more specific profile applies, and if set to UACC NONE, it denies access. Using a backstop profile in this way denies access unless the user has access to a more specific profile. One advantage to using a backstop profile, instead of just letting access fail because no profile is defined, is that it can be audited -- RACF audit records can record both successful and failed accesses. A backstop profile should be defined for each of the WebSphere MQ classes. For the MQADMIN class, you might want to define backstop profiles for alternate user security, and command resource security for the various types of command resource security in addition to a backstop profile that protects the entire MQADMIN class. The following example shows a backstop profile defined for queue manager CSQ1 for RACF Class MQQUEUE:

Example 9. A backstop profile for the MQQUEUE class

Profiles for commands

Since the product itself defines all MQSC commands, the same set of commands exists for every z/OS queue manager. Consequently, once you develop a satisfactory scheme to secure commands, it should be possible to implement that same scheme -- that is, the same set of MQCMDS profiles, with the same or similar access lists -- for all queue managers. Or, you might want to have one scheme for protecting commands for test and other non-production queue managers, and a second more restrictive scheme to protect commands on your production queue managers. However, a situation where commands are protected differently for each individual queue manager is likely to frustrate users, and it implies that a careful plan for who should have access to which commands has not been implemented. Role-based security is the most straightforward way to organize commands for security purposes. For more information on the roles that might need access to the various commands, and how to divide up the commands between those roles, see WebSphere MQ for z/OS security.

Profiles to protect SYSTEM resources

WebSphere MQ has some resources that use a high-level qualifier of SYSTEM. Some of them are resources that are required for the queue manager to execute, while others are defined as models. Since these are either critical infrastructure, or models that provide defaults for the resources defined for your applications, you need to protect them. You can do so by limiting access to the commands that can affect them, and also through command resource security. Here are some considerations for SYSTEM resources:

  • SYSTEM queues -- that is, queues with a high level qualifier of SYSTEM -- are used by the queue manager, the channel initiator, the MQ Administrators, and other users. The product documentation contains a table titled "Access required to the SYSTEM queues by WebSphere MQ" with details about which users need which level of access to the SYSTEM queues. You can find this table in the manuals or under the topic "System queue security" in the WebSphere MQ V7 information center. This table can be a guide for implementing least privilege, so that only the users who need access are granted access.
  • The importance of securing context for the SYSTEM.COMMAND.INPUT queue and its alias was described above under Special considerations for CONTEXT security for the command queue.
  • SYSTEM.BASE.TOPIC is the topic used as the parent for any topics that otherwise do not have a parent topic. The authorization to publish or subscribe to SYSTEM.BASE.TOPIC lets a user publish or subscribe to any topic. So, consider defining a MXTOPIC profile for it with a UACC of NONE, and no users in the access list. If you do that, then you need to define additional TOPIC objects with related MXTOPIC profiles, and grant access as needed.
  • Use command resource security to ensure that only the queue manager's administrators can modify SYSTEM resources of any kind, such as queues and channels.
  • Though RACF profiles are not used for this, it is a common practice to make the SYSTEM.* channels that receive messages unusable by coding an invalid userid (or a userid with no access) for their MCAUSER.

Profiles for local application resources

RACF profiles must be defined to protect the local application objects that you define for your queue managers. Usually you can protect application resources by defining generic profiles to protect a group of resources, as long as the group of resources uses a naming convention so that it is possible to define a generic profile that applies to them alone. The typical convention for application objects is to begin the name, such as a queue name, with an application-specific high-level qualifier. Define generic profiles so that they apply to a set of objects that share security requirements, such as a set of queues to which all users of an application need the same level of access. If a profile applies to objects that should not share the same access list, then obviously that profile is too generic. In that case you need to define additional generic, fully qualified or group profiles until the profiles provide enough granularity to limit access to those with a valid need for it.

  • It should be possible to protect queues with generic profiles, which -- as just described -- apply to a set of queues that can share an access list. If you need to give some users get access but not put (or put access but not get), then you can define QALIAS definitions. For more information, see the topic "Using alias queues to distinguish between MQGET and MQPUT requests" in the WebSphere MQ V7 information center.
  • TOPIC objects and the RACF profiles that match them secure topic trees. Remember that access to a TOPIC object implicitly grants access to any topic strings at or below that TOPIC in the topic tree. Therefore topic trees and the TOPIC objects related to them need to be planned carefully, so that you will be able to secure topics as required. That is, you will need to plan for security requirements when you design the layout of your topic trees.
  • Security for queue context -- beyond that for SYSTEM.COMMAND.INPUT -- depends on whether you will use UserIdentifier or other fields in the context part of the message descriptor. As a starting point, a backstop profile, and any profiles for application queues, can be defined to protect all context as UACC NONE, so that no applications can modify context by passing or setting it. If no applications will use any feature that relies on the value of the UserIdentifier (or some other field in context), then no application userids should need to have an access level higher than NONE to the profiles that protect context. (MCA channels need authorization to set context for the queues that they put to -- for more information, see the topic "Security considerations for the channel initiator on z/OS" in the WebSphere MQ V7 information center. ) On the other hand if you do have applications that rely on the context fields, for example that use ALTERNATE USER security, or channels that use PUTAUT(CTX), then you need to examine context security more closely. If your queue managers execute programs that need to pass or set context, then implement profiles and least privilege so that only the users that require this authority have it granted to them. Since the authorization to set context allows the user to override the UserIdentifier, if you are using any feature that relies on the UserIdentifier, be careful about granting set authority.
  • Similar to context security, if you do not plan to use alternate user security, define a backstop profile (CSQ1.ALTERNATE.USER.**) with a UACC of NONE and do not grant any users access to it. If you do plan to allow alternate users, in addition to the backstop profile, your can define profiles for individual userids, for a generic userid (probably not useful since userids are typically not defined in a way that makes it easy to protect a set of them with a generic profile), or for a group of userids (using the GMQADMIN or GMXADMIN class).
  • You can define command resource security profiles for application resources, such as application queues, to control which users can define which queues. In a development environment, you might use them to allow the analysts for different applications to define only the queues for their applications. But even if you will permit only the MQ administrators to define queues, command resource security profiles can still be useful as a means to, at least partially, enforce naming standards. That is, if a backstop profile has been defined for MQADMIN (or for a specific type of command resource, such as queues) with UACC(NONE) and an empty access list, then the default is for no one to have permission to define any resources. If in addition to the backstop profile, you define SYSTEM and application profiles, then only resources (such as queues) that match those command resource security profiles can be defined.

Userids that need access to the profiles

Determining which users or groups need to be in the access list of the profiles that have been defined, for batch, CICS, and IMS connections is straightforward:

  • Batch connections can have only one userid associated with them, and the source of that userid, such as the job userid or TSO userid, is usually obvious.
  • For CICS, depending on the region userid's access to RESLEVEL, the region userid, and possibly the transaction userid will be checked for access.
  • For IMS, depending on the region userid's access to RESLEVEL, the region userid, and possibly a secondary userid will be checked for access. For more information, see the topic "User IDs checked for IMS connections" in the WebSphere MQ V7 information center.
  • If you are using the CICS bridge or the IMS bridge, see the product documentation for additional guidance.

Channel security is more complex because it depends on several settings:

  • RESLEVEL controls how many userids will be checked.
  • The channel userid for channels that use the TCP/IP protocol defaults to the channel initiator's userid, but if the channel uses SSL, a userid can be assigned through the SSL client's certificate.
  • The PUTAUT parameter on the channel itself controls which userids (for example, MCAUSER, alternate user) are checked for authorization.

Much of the article WebSphere MQ for z/OS security is about channel security, so it contains additional information on this topic.


The product documentation for WebSphere MQ security on z/OS is extensive, and this article provided an overview to help someone unfamiliar with this subject to understand the basics. For many of the subjects that are too detailed to describe in depth in an introductory article like this one, you can get additional information by searching in the WebSphere MQ V7 information center using the topics quoted throughout this article.

The RACF classes defined for WebSphere MQ Security on z/OS provide many options. The starting point when setting up security for a new queue manager, or reviewing the profiles for an existing queue manager, should be to consider what needs to be secured. That is, who should be permitted to issue which commands? Who can get and put messages on which queues? Should administrators be blocked from accessing (or even browsing) messages on some queues? Once you have documented your security requirements, then you can start designing profiles to best secure your queue managers and their application messages. Careful planning will help you organize profiles that provide the security you need, yet are simple enough so their purpose is easy to understand.

Downloadable resources

Related topics

  • WebSphere MQ resources
  • WebSphere resources
    • developerWorks WebSphere developer resources
      Technical information and resources for developers who use WebSphere products. developerWorks WebSphere provides product downloads, how-to information, support resources, and a free technical library of more than 2000 technical articles, tutorials, best practices, IBM Redbooks, and online product manuals.
    • developerWorks WebSphere application connectivity developer resources
      How-to articles, downloads, tutorials, education, product info, and other resources to help you build WebSphere application connectivity and business integration solutions.
    • Most popular WebSphere trial downloads
      No-charge trial downloads for key WebSphere products.
    • WebSphere forums
      Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
    • WebSphere on-demand demos
      Download and watch these self-running demos, and learn how WebSphere products and technologies can help your company respond to the rapidly changing and increasingly complex business environment.
    • developerWorks WebSphere weekly newsletter
      The developerWorks newsletter gives you the latest articles and information only on those topics that interest you. In addition to WebSphere, you can select from Java, Linux, Open source, Rational, SOA, Web services, and other topics. Subscribe now and design your custom mailing.
    • WebSphere-related books from IBM Press
      Convenient online ordering through Barnes & Noble.
    • WebSphere-related events
      Conferences, trade shows, Webcasts, and other events around the world of interest to WebSphere developers.
  • developerWorks resources
    • developerWorks blogs
      Join a conversation with developerWorks users and authors, and IBM editors and developers.
    • developerWorks Webcasts
      Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts to half-day and full-day live sessions in cities worldwide.
    • developerWorks podcasts
      Listen to interesting and offbeat interviews and discussions with software innovators.
    • developerWorks on Twitter
      Check out recent Twitter messages and URLs.
    • IBM Education Assistant
      A collection of multimedia educational modules that will help you better understand IBM software products and use them more effectively to meet your business requirements.


Sign in or register to add and subscribe to comments.

ArticleTitle=Getting started with WebSphere MQ for z/OS security