Comparing WebSphere MQ security on distributed platforms and z/OS

This article compares security for WebSphere MQ on the distributed platforms using OAM to security for WebSphere MQ for z/OS using RACF. While the same WebSphere MQ objects -- queues, channels, and so on -- are protected on all platforms, what can be protected and how it is secured differ greatly between distributed and z/OS. An understanding of these differences is essential for architects, administrators, and developers who may need to work across platforms. Furthermore, understanding security strengths and weaknesses across platforms leads to a deeper understanding of how MQ security works.

Share:

Tom Schneider (tschne1@us.ibm.com), Team Leader, Integrated Technology Delivery, WebSphere MQ, 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 tschne1@us.ibm.com.



17 March 2010

Also available in Chinese

Introduction

This article compares how IBM® WebSphere® MQ security is implemented on distributed platforms (UNIX® and Windows® in particular) versus how it is implemented on z/OS®. The article has two main goals:

  • Help those who are familiar with one security implementation to become acquainted with the other.
  • Provide a fresh perspective on security on the platform you are familiar with, by comparing it to a different way of implementing security.

OAM and RACF

The obvious difference in how WebSphere MQ security is implemented on distributed platforms compared to z/OS is that the Object Authority Manager (OAM) is used on distributed, and RACF is used on z/OS. Actually, on distributed, a different authorization service could be installed, and similarly on z/OS a different external security manager can be configured. However, this article assumes that the OAM and RACF are being used, and discusses security on the distributed platforms and z/OS based on that assumption.

The OAM is a component of WebSphere MQ on distributed, and was written to implement security since there was no general facility available to secure WebSphere MQ. RACF implements security through classes, which are RACF entities used to secure a specific type of resource. Since new classes can be defined to RACF, when WebSphere MQ was developed, classes were added to RACF specifically for WebSphere MQ, such as the MQQUEUE class which is used to secure queues.

The OAM stores authorization records, or profiles, on a queue: SYSTEM.AUTH.DATA.QUEUE. On the other hand, RACF stores its profiles in the RACF database, and therefore security on z/OS is defined independently of the queue manager. The RACF profiles to protect a queue manager's resources can be defined even if the queue manager has not yet been created. Similarly, the queue manager and all the data sets that support it can be deleted, but the RACF profiles will still exist until they are deleted from the RACF database.

Who can administer security differs too. On distributed, users in the mqm group can issue the setmqaut command to grant or revoke access. Users in the mqm group can also issue the dmpmqaut and dspmqaut commands to dump or display authority. So the mqm group contains not only the administrators for the queue manager, but also the security administrators. On z/OS it's possible to grant the authority to define profiles in the RACF classes used by WebSphere MQ to the same users who are the queue manager's administrators. But it is also possible, and perhaps more common, to reserve the right to define profiles, and to grant access to those profiles,to the RACF administrators. In that case a completely different team than the team that administers WebSphere MQ would control security for the queue manager. The queue manager's administrators might not even have the authority to display what profiles are defined, or the access lists for those profiles.

Another significant difference between the OAM and RACF is that RACF defines a Universal Access (UACC) for all profiles. The UACC sets a default level of access for the profile. Any user or group which does not have a level of access granted to it specifically will get the access granted by UACC. UACC and its implications are discussed below when generic profiles are compared. There are other functional differences between the OAM and RACF, some of which will be discussed near the end of this article.

How is access granted?

The OAM grants access to WebSphere MQ objects through individual authorities, such as altusr, browse, chg, clr, connect, crt, get, put and so on. This allows authorities to be granted discretely, that is, a user can be permitted to browse a queue and put to a queue, but not to get from a queue. Also, administrative authorities, such as the authority to create a queue (crt) or delete a queue (dlt) can be granted through the same profile that is used to grant API (get or put) access to the queue.

On the other hand, RACF has a set of authorizations which are used for all general resources: NONE, READ, UPDATE, CONTROL and ALTER. These are used for all RACF classes, not just the classes defined for WebSphere MQ. So, these authorizations do not map directly to WebSphere MQ specific actions like get or browse. Also, authority in RACF is granted in a cumulative way. For example, if a group has CONTROL access, then the users in that RACF group get the access provided by READ and UPDATE as well as CONTROL. The following table shows what MQI actions a user ID can perform if it has the access level listed.

Table 1. Access levels for the MQQUEUE class.
Level of accessWhat that access allows
NONEno access
READbrowse and inquire (MQINQ)
UPDATEGet, Put and any access allowed by READ
CONTROLNot defined for the MQQUEUE class, so it allows the same access as UPDATE
ALTERMQSET, and any access allowed by UPDATE and READ

The cumulative way that access is granted explains why the RACF implementation of security for queues does not allow get and put access to be granted independently. If a user has UPDATE access to the MQQUEUE profile that protects a queue, this allows it to both get and put.

More about why GET and PUT cannot be granted independently with RACF

CONTROL access is not defined for the MQQUEUE class, that is, only READ, UPDATE and ALTER are used, so if CONTROL is granted, it provides the same level of access as UPDATE would. Even if CONTROL had been defined for MQQUEUE, and suppose that it had been used to grant the authority to put to the queue, this would still not have solved the issue of not being able to grant get and put access independently. In that case someone with UPDATE access could get from the queue, and someone with CONTROL access could put to the queue, but would also be permitted to get messages off the queue since CONTROL would provide the privileges already assigned to READ and UPDATE.

Also, since RACF only provides the five levels of access (NONE, READ, UPDATE, CONTROL and ALTER), and NONE means no access to the resource, there are only four levels of access remaining that can be assigned to any profile. This requires RACF to use several different profiles in various classes to control access to a resource. For example, for a queue, an MQQUEUE profile is used to control MQI access to the queue, but other profiles in the MQADMIN class are used to control context and alternate user security. Profiles in the MQCMDS class control access to commands (such as DEFINE QLOCAL) that provide the ability to define or alter a queue. Then additional profiles in the MQADMIN class control command resource security, that is, the authority to define queues that have a specific name, for example any queues that begin with APP1. While this means that the RACF profiles used for security on z/OS provide granularity and flexibility, they are also complex since a set of profiles has to be defined to protect a queue.

This table compares the access setmqaut can grant for queues, to the RACF class, profile and access level needed to get similar access on z/OS:

Table 2. comparison of the access granted by the OAM and what would provide similar access in RACF
setmqaut access to profile APP1.QUERYwhat that access providesRACF accessRACF class and the profile in that classwhat that access provides
browsebrowse the queueREADMQQUEUE hlq.APP1.QUERYbrowse (and inquire on the queue)
chgalter the queueALTERMQADMIN hlq.QUEUE.APP1.QUERYalter the queue (access to the command to alter the queue in the MQCMDS class would also be needed)
clrclear the queueALTERMQADMIN hlq.QUEUE.APP1.QUERYclear the queue (access to the CLEAR QLOCAL command in the MQCMDS class would also be needed)
crtdefine the queueALTERMQADMIN hlq.QUEUE.APP1.QUERYdefine the queue (access to the command to define the queue in the MQCMDS class would also be needed)
dltdelete the queueALTERMQADMIN hlq.QUEUE.APP1.QUERYdelete the queue (access to the command to delete the queue in the MQCMDS class would also be needed)
dspdisplay the queuen/an/aNo specific authorization is needed to the queue, as long as the user has access to issue the DISPLAY command for the type of queue in the MQCMDS class
getget messages from the queueUPDATEMQQUEUE hlq.APP1.QUERYget (and put) messages, as well as the authorities already provided by READ
putput messages to the queueUPDATEMQQUEUE hlq.APP1.QUERYput (and get) messages, as well as the authorities already provided by READ
inqinquire on the queueREADMQQUEUE hlq.APP1.QUERYinquire on the queue (and browse)
passallpass all contextREADMQADMIN hlq.CONTEXT.APP1.QUERYpass all or identity context
passidpass ID contextREADMQADMIN hlq.CONTEXT.APP1.QUERYpass all or identity context
setMQSET the queueALTERMQQUEUE hlq.APP1.QUERYMQSET the queue (as well as all the authorities already provided by UPDATE and READ)
setallset all contextCONTROLMQADMIN hlq.CONTEXT.APP1.QUERYset all context (as well as the access provided by READ and UPDATE to this same profile)
setidset ID contextUPDATEMQADMIN hlq.CONTEXT.APP1.QUERYset identity context (as well as the access provided by READ to this same profile)

The RACF profiles shown in the table would be prefixed by the queue manager name (or if the queue manager belongs to a queue sharing group, they can also be prefixed with the queue sharing group name). This is represented in the samples above by hlq. For example, if they were defined for queue manager CSQ1, then the profile for the MQQUEUE class would be CSQ1.APP1.QUERY. Additionally, the MQADMIN class profiles contain the string QUEUE for profiles used for command resource security, or CONTEXT, for the profiles used to control access to message CONTEXT.

Example of granting browse and put access

The following command, based on an example from the WebSphere MQ documentation, shows setmqaut being used to grant group GROUP1 browse and put access, and revoke get access. This is being done for queue APP1.QUERY, on queue manager QMGR1:

Example 1. setmqaut command for queue APP1.QUERY.
setmqaut -m QMGR1 -t queue -n APP1.QUERY -g GROUP1 +browse -get +put

Here is a nearly equivalent RACF command, assuming there is a MQQUEUE class profile defined specifically for queue APP1.QUERY. This would effectively grant GROUP1 the authority to browse, inquire, get or put messages for queue APP1.QUERY on queue manager CSQ1.

Example 2. RACF PERMIT command for profile APP1.QUERY.
PERMIT CSQ1.APP1.QUERY CLASS(MQQUEUE) ID(GROUP1) ACCESS(UPDATE)

There are several things to point out in these commands:

  • The z/OS command would grant access to not only browse and put, but also to get and inquire. It would be possible to grant only browse and inquire, and only put access if alias queues were defined, and GROUP1 was granted READ access to the alias that is put disabled, and UPDATE access to the alias that is get disabled. (Details about how to do that are in the System Setup Guide.) However, that would require any programs using the queue to be aware that two different names would need to be used to access the queue, depending on whether browse or put access was required. This example shows that the WebSphere MQ classes in RACF do not provide as granular of access for MQI operations as the OAM does.
  • Regarding the access assigned by setmqaut, the command above permits browse and put access, and takes away get access. Since the access granted by setmqaut is discrete, you cannot tell from the command above what access GROUP1 does, or does not have to queue APP1.QUERY outside of the access granted by this command. For example, whether GROUP1 has the authority to pass ID context (passid) cannot be determined just by looking at this command. On the other hand with RACF, UPDATE access supersedes any access which had previously been granted to GROUP1, since access is cumulative.

Example of granting authority to pass context

This setmqaut grants get, put and passall to group GROUP1.

Example 3. Sample setmqaut command to pass all context
setmqaut -m QMGR1 -t queue -n APP1.QUERY -g GROUP1 +get +put +passall

Similarly, the following PERMIT commands would allow GROUP1 to get or put messages, and to pass all context.

Example 4. Sample RACF PERMIT commands for passing context
PERMIT CSQ1.APP1.QUERY CLASS(MQQUEUE) ID(GROUP1) ACCESS(UPDATE) 
PERMIT CSQ1.CONTEXT.APP1.QUERY CLASS(MQADMIN) ID(GROUP1) ACCESS(READ)

This example shows that the WebSphere MQ classes in RACF require you to grant access to two profiles (one in class MQQUEUE and one in class MQADMIN) in order to grant the authority to get messages and be able to pass their context.

How are connections secured?

Using the OAM, permission to connect to the queue manager is granted by the connect authority. In the following example, authority to connect to queue manager QMGR1 is being granted to group1.

Example 5. Sample setmqaut command to grant permission to connect to a distributed queue manager.
setmqaut -m QMGR1 -t qmgr -g group1 +connect

On z/OS the MQCONN RACF class is used to secure the ability to connect to a queue manager. There are four different profiles defined for a queue manager in the MQCONN class. For each profile, an access level of NONE prevents access, and an access level of READ (or higher) allows the user or group to connect. The following table describes the four profiles.

Table 3. Profiles defined in the MQCONN class, and the access that they protect.
profilewhat type of connection READ access allows
hlq.BATCHbatch jobs, TSO applications, DB2 stored procedures and access through Unix System Services (USS)
hlq.CHINaccess by the channel initiator
hlq.CICSaccess for a CICS address space
hlq.IMSaccess for IMS control and application processing regions

(In the previous MQCONN samples, hlq would be either the queue manager, or queue sharing group name.)

An important difference between connection security on distributed and on z/OS is that for the channel initiator, CICS and IMS, the authority to connect is granted to the region. For example, the user ID for the channel initiator address space needs the authority to connect to the queue manager, but the channels themselves do not. They use the channel initiator's connection. In contrast on distributed, any MCAUSER that needs to connect to the queue manager will need +connect authority. Similarly for CICS, the CICS region's user ID has to have permission to connect, but the user IDs for the transactions which run in the CICS region do not.

Here is an example of a RACF PERMIT command to grant the user ID for the channel initiator permission to connect to queue manager CSQ1.

Example 6. Sample RACF PERMIT command to grant permission for a channel initiator to connect to queue manager CSQ1.
PERMIT CSQ1.CHIN CLASS(MQCONN) ID(CSQ1CHIN) ACCESS(READ)

Differences in GENERIC profiles

On the surface GENERIC profiles appear to be similar on distributed and z/OS. For example, a single asterisk and a double asterisk have nearly the same meaning. However, there is a fundamental difference in how generic profiles are applied.

On distributed, a profile does not have any default access level (such as a UACC), so several different profiles can apply to the same object. That is, different user IDs or groups can have their access to a WebSphere MQ object controlled by different generic profiles. This is demonstrated by this example from the Version 7.0 WebSphere MQ System Administration Guide:

Example 7. From the WebSphere MQ Administration manual, how generic profiles are applied with the OAM
The following examples show the use of the dmpmqaut control command to dump 
authority records for generic profiles... 
 
This example dumps all authority records with a profile that matches queue a.b.c. 

dmpmqaut -m qmgr1 -n a.b.c -t q 

The resulting dump would look something like this: 

profile: a.b.c 
object type: queue 
entity: Administrator 
type: principal 
authority: all 
- - - - - - - - - - - - - - - - - 
profile: a.b.* 
object type: queue 
entity: user1 
type: principal 
authority: get, browse, put, inq 
- - - - - - - - - - - - - - - - - 
profile: a.** 
object type: queue 
entity: group1 
type: group 
authority: get

In the example above from the manual, the entities Administrator, user1 and group1 all have different levels of access. Administrator has access through a fully qualified profile (that is, a profile that matches the name of the queue). However, user1 has access through one generic profile, and group1 has its access through a different generic profile.

On z/OS a RACF generic profile is applied in a completely different way due to the UACC on the profile. In the following example for queue A.B.C (the name of the queue has been folded to upper case for the z/OS example), if the same three profiles were defined to RACF, (that is, A.B.C, A.B.* and A.**), the fully qualified A.B.C profile would control access to the queue since it is the best match. The user IDs and groups that had access granted or denied specifically because they are in the access list of the profile, would, obviously, have the access that they were granted. All other users and groups would have the access assigned to the UACC.

For example, in the following output from a RL (RLIST) command, the UNIVERSAL ACCESS (that is, UACC) is NONE, and several groups and user IDs have been granted a specific level of access. (Much of the output of the RL command has been edited out of this example and only the lines that show the profile name, the UNIVERSAL ACCESS and the access list have been retained.)

Example 8. RLIST of a RACF profile
RL MQQUEUE CSQ1.A.B.C ALL     

CLASS            NAME                                                  
-----            ----                                                  
MQQUEUE    CSQ1.A.B.C                                    
                                                                 
LEVEL  OWNER      UNIVERSAL ACCESS  YOUR ACCESS  WARNING         
-----  --------   ----------------  -----------  -------         
 00    MQADMNS         NONE              ALTER    NO             
                       
USER      ACCESS       
----      ------       
GROUP1    ALTER        
MONITOR   ALTER        
CSQ1CIU   UPDATE             
MQ77CIU   UPDATE

In this case GROUP1 has ALTER access. But if user ID USER1 tried to access this queue (assuming USER1 is not connected to one of the groups in the access list, such as GROUP1) it would get an access violation, because USER1 is not in the access list for profile CSQ1.A.B.C, so it would default to the UACC, which is NONE. If there were another MQQUEUE class profile named CSQ1.A.B.* and USER1 had been granted ALTER access to it, that would not matter since the fully qualified profile would take precedence over the generic profiles, which are not as close of a match.

In short, the best match for a given user ID or group will be the profile that applies on distributed, but best match in this case applies only to profiles that include the user ID or group in the access list. That is, different generic profiles can be applied to different user IDs or groups. On z/OS, the best match based on the name of the resource itself is used, without considering which users or groups are in its access list. The same profile applies to all user IDs or groups, since they are either in the access list or are subject to the UACC.

The way the OAM implements generic profiles has the advantage that it is easy to assign a given group a level of access to a set of queues (regardless of what profiles have already been defined), since you can define a profile that will apply only to that group. On the other hand, the RACF implementation is probably more straightforward, because the same profile will be applied consistently to all user IDs or groups.

mqm group versus no mqm group

Perhaps the most significant difference between security on z/OS and distributed platforms is the presence of a user ID (on UNIX), and a group (on all the distributed platforms) with unlimited authority. The mqm user ID and group are significant for these reasons:

  • The queue manager and the processes it starts will run under mqm, or one of the user IDs in the mqm group, and mqm will typically be the default for receiving type channels (RECEIVER, REQUESTER, CLUSRCVR or SVRCONN) if the MCAUSER is not set.
  • The mqm user ID, or a user ID connected to the mqm group, is also used by the people who are the administrators of the queue manager.
  • The mqm user ID and group are essentially exempt from security enforced by the OAM, since their access cannot be revoked.

In contrast, there is no similar user ID or group on z/OS. The queue manager and channel initiator both run as started tasks, and each can run under its own user ID. The queue manager's user ID apparently has access to all WebSphere MQ objects without requiring access to be granted explicitly. On the other hand, the user ID for the channel initiator is essentially just another user ID. It needs access to many WebSphere MQ resources, but access must be granted to them -- it is not given automatically.

On the distributed queue managers, the fact that the queue manager, its processes, and the human administrators of the queue manager all have mqm authority creates challenges, because all of these users are running with the same authority, which from the perspective of the OAM, is unlimited. On z/OS, you can limit the authority of the channel initiator's user ID, and the administrators of the queue manager. That is, least privilege can be applied to the channel initiator, so that it is given access only to the objects and commands that it requires. Similarly, the persons who administer the queue manager do not necessarily need access to all objects or commands. For example, security can be configured so that the administrators can define queues, but not access the messages on them.

Finally, on z/OS it is prudent not to connect the queue manager or channel initiator to the same RACF group as the administrators, since the queue manager or channel initiator are not going to have the same access requirements as the people administering the queue manager. So if people are connected to the same RACF group as the queue manager or channel initiator, least privilege will not be in effect, because the user IDs are likely to be granted access through the RACF group they share to authorities that they do not require.

To summarize, on z/OS the channel initiator and the human administrators of the queue manager do not need to be configured with unlimited access. Take advantage of this and grant these users only the access they require.

Channel security

There are several significant differences between security for channels on z/OS and distributed. The first is the connection used. On distributed each channel establishes its own connection. On z/OS, all channels use the one connection established by the channel initiator address space, that is, the connection associated with the user ID of the channel initiator's started task. This becomes particularly significant on z/OS, if the channel initiator's user ID is given an elevated level of access to the MQADMIN class RESLEVEL profile. (RESLEVEL is discussed in a previous article in developerWorks, "WebSphere MQ for z/OS security").

A second difference is the number of user IDs that are associated with a channel. On distributed, a receiving channel has one user ID, the MCAUSER. The MCAUSER can default to mqm, unless it is set (for example by the MQI client, or by a security exit) or is hardcoded on the channel definition.

z/OS receiving channels have two user IDs, the channel user ID (which is often overlooked) and the MCAUSER. The channel user ID for a TCP/IP channel defaults to being the channel initiator's user ID. If SSL is used on the channel, then optionally the channel user ID can be set. If it is set, it is set in one of two ways:

  • It is the user ID associated with the channel's certificate when you added it to the key ring.
  • Or, it is the user ID assigned through the RACF Certificate Name Filter (CNF) facility. A CNF can be used, for example, if the remote queue manager's certificate was signed by a CA, and only the CA's certificate is in the local queue manager's key ring.

The MCAUSER is assigned in a similar way as it is on distributed, except, rather than defaulting to mqm, it defaults to the channel initiator's user ID. On distributed, its undesirable for MCAUSER to default, since it will be mqm which has unlimited access, both to queues and commands. On z/OS, the effect of a channel defaulting to the channel initiator's user ID varies according to two things:

  • The level of access the channel initiator's user ID has to the MQQUEUE and MQADMIN class profiles that protect queues and their context.
  • For SVRCONN channels, the commands that can potentially be entered through the channel depend on what commands the channel initiator's user ID has (or has not) been granted. Defaulting to the channel initiator's user ID should not provide full administrative access.

As was already discussed, the user ID for the channel initiator should not be granted access to any resources (queues, commands, etc.) that it does not require. Also, it is important that the user ID for the channel initiator is not granted a level of access to the RESLEVEL profile which will cause MQI security checks to be bypassed for the channel initiator and channels, since they use the channel initiator's connection to the queue manager.

Functional differences between OAM and RACF

Besides the differences that have already been discussed, there are differences in the functionality provided by the OAM versus RACF.

One very significant difference is the user ID or group that is given access by default when an object is defined. With the OAM, full access is granted to the user ID that created the object. On UNIX, since access is managed at the group level, this means that the OAM gives access to the primary group for the user ID. This requires administrators to either log on as the mqm user ID when creating objects, so that only the mqm group is granted access by default, or if a personal user ID will be used to define the object, to be aware of what that user ID's primary group is. For example if the administrator defines an object while logged on with a personal user ID, and the user ID's primary group is staff, then access is granted to staff. Obviously, the queue manager's administrators must be very careful about the primary group assigned to the user ID that they are using to define WebSphere MQ objects. Otherwise access can inadvertently be granted to a group such as staff, which should not have access.

On z/OS, the RACF SETROPTS setting, either ADDCREATOR or NOADDCREATOR, controls the access granted to the user who defines the profile. If ADDCREATOR is in effect, then the user ID defining the profile is given ALTER access to it. This access is given to the user ID only, not to any groups it is a member of. If NOADDCREATOR is in effect, then the user ID defining the profile will not be given any access to it by default.

Since the OAM secures WebSphere MQ only, it is easy to create a listing of all WebSphere MQ profiles used by the queue manager with the dmpmqaut control command. In contrast, on z/OS, the RACF profiles for WebSphere MQ can be spread across various classes, including the group classes, and with WebSphere MQ V7, mixed case classes, so dumping a listing of all the profiles that are in effect is not quite as simple. A series of RLIST commands must be used to display the various WebSphere MQ classes.

Finally, RACF provides some features that the OAM does not. The AUDIT parameter on a RACF profile provides a way to audit both successful and unsuccessful attempts to access any resources that the profile protects. These audit records are saved in the SMF data sets along with other z/OS system information. WebSphere MQ administrators and users should be prevented from tampering with the SMF data sets. Separation of duties is also easier to enforce with RACF, since one or more groups that are completely separate from the WebSphere MQ administrators can control the ability to define security profiles and grant access to them (as well as to audit what is done with that access).

Conclusion

This article has discussed differences between how security is implemented for WebSphere MQ on z/OS compared to the distributed platforms such as UNIX and Windows. While the resources to be protected are mostly the same between z/OS and distributed, there are differences in the security that is available to protect them. In particular, the following differences were noted:

  • Since RACF has a limited set of authorizations (NONE, READ, UPDATE, CONTROL and ALTER) that are not specific to WebSphere MQ, it often takes several profiles in several different RACF classes to protect the same resource which the OAM, using WebSphere MQ specific authorizations, can protect with one profile.
  • RACF provides a default level of access on a profile, the Universal Access (abbreviated UACC). Any user or group that does not have access granted to it specifically gets the access level assigned to the UACC. OAM profiles do not have anything corresponding to the UACC; a user is either included in the access list or is not.
  • The way that generic profiles are implemented is different. The OAM looks for the best matching profile for the resource, based on profiles which contain the user's user ID or group. RACF matches strictly on the resource name. If the user is not in the access list for the best matching profile, then they get the access provided by the UACC.
  • On distributed, the mqm group is used by the queue manager, the queue manager's administrators, and can be used as a default by channels. mqm has unlimited access, and you cannot revoke its access. In contrast on z/OS, the administrators and channel initiator user ID are subject to the same security checks as any other user. You should grant them access only to the resources that they require.
  • On z/OS, all channels use the connection established by the channel initiator. On distributed, each channel has its own connection. This can become important on z/OS if the channel initiator has an access level greater than NONE to the RESLEVEL profile.
  • The number of user IDs that a channel has differs between distributed and z/OS. The default for MCAUSER differs as well.
  • On distributed, users in the mqm group are the administrators for both the queue manager, and security for the queue manager. In contrast, on z/OS is it possible for two completely separate groups to control queue manager administration and security administration.

There is much more about this topic that could be discussed, but this article has pointed out what should be the most prominent differences. If you think there are other significant issues to discuss about this topic, readers are invited to post them as comments, or to contact the author directly.

Resources

Comments

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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=475033
ArticleTitle=Comparing WebSphere MQ security on distributed platforms and z/OS
publish-date=03172010