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.

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.

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:

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:

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.

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.

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.

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.

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.

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

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:

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

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

• WebSphere MQ for z/OS security
  This developerWorks article describes WebSphere MQ security on z/OS, including the RESLEVEL profile.
  
  
• WebSphere MQ for z/OS System Setup Guide V6.0
  Information on WebSphere MQ for z/OS RACF classes.
  
  
• WebSphere MQ for z/OS System System Administration Guide
  Information on OAM and its related commands, such as setmqaut.
  
  
• z/OS V1R10.0 Security Server RACF Command Language Reference
  Information about the commands used to maintain RACF profiles, including the RACDCERT command, which is used to manipulate digital certificates and certificate name filters.
  
  
• Principle of least privilege
  Definition from Wikipedia.
  
  
• Concept of separation of duties
  Definition from Wikipedia.
  
  
• WebSphere MQ developer resources page
  Technical resources to help you design, develop, and deploy messaging middleware with WebSphere MQ to integrate applications, Web services, and transactions on almost any platform.
  
  
• WebSphere MQ product page
  Product descriptions, product news, training information, support information, and more.
  
  
• WebSphere MQ documentation library
  WebSphere MQ product manuals.
  
  
• WebSphere MQ V7 information center
  A single Web portal to all WebSphere MQ V7 documentation, with conceptual, task, and reference information on installing, configuring, and using WebSphere MQ V7.
  
  
• IBM Redbook: WebSphere MQ V7 features and enhancements
  Describes the fundamental concepts and benefits of message queuing technology, describes the new features in V7, and provides a business scenario that shows those features in action.
  
  
• WebSphere MQ V7 trial download
  A 90-day, full featured, no-charge trial of WebSphere MQ V7
  
  
• WebSphere MQ support page
  A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
  
  
• WebSphere MQ public newsgroup
  A non-IBM forum where you can get answers to your WebSphere MQ technical questions and share your WebSphere MQ knowledge with other users.
  
  
• WebSphere MQ SupportPacs
  Downloadable code, documentation, and performance reports for the WebSphere MQ family of products.
  
  
• WebSphere MQ FTE Information Center
  A single Web portal to all WebSphere MQ FTE V7 documentation, with conceptual, task, and reference information on installing, configuring, and using WebSphere MQ FTE
  
  
• WebSphere MQ FTE forum
  Get answers to your WebSphere MQ FTE technical questions and share your WebSphere MQ FTE knowledge with other users.
  
  
• WebSphere MQ FTE V7 trial download
  A 90 day, full featured, no-charge trial of WebSphere MQ FTE V7
  
  
• 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.
  
  
• developerWorks WebSphere business process management developer resources
  WebSphere BPM how-to articles, downloads, tutorials, education, product info, and other resources to help you model, assemble, deploy, and manage business processes.
  
  
• developerWorks WebSphere SOA and Web services developer resources
  How-to articles, downloads, tutorials, education, product info, and other resources to help you design and build WebSphere SOA and Web services 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, watch, and learn what WebSphere products and WebSphere-related technologies can do for your company.
  
  
• 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.
  
  
• Trial downloads for IBM software products
  No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
  
  
• 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.
  
  

About the author

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

Rate this article

Comments

Back to top

Table of contents

• Introduction
• OAM and RACF
• How is access granted?
• How are connections secured?
• Differences in GENERIC profiles
• mqm group versus no mqm group
• Channel security
• Functional differences between OAM and RACF
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere MQ
• Briefing: WebSphere flexible business processes
• Buy: WebSphere MQ

Dig deeper into WebSphere on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers