Managing WebSphere MQ object security

This section describes how to manage user access to various areas and operations of TrueSight Middleware and Transaction Monitor (TMTM) and the data it handles.

The TMTM Agent can be configured to run as either a secure or unsecure agent.

  • Using a secure agent forces the user to supply a WebSphere MQ authorized user account to change or use secure WebSphere MQ objects. 
  • An unsecure agent does not verify user account authorization.

Related topic

Security-planning 

Note

TMTM enforces WebSphere MQ object security only on AIX, HP NonStop Server, HP-UX, Linux, zLinux, Tru64 UNIX, Solaris, z/OS and Windows.

Note

When the TMTM Extensible Agent is in unsecured mode (by default), all requests are performed under the user that starts the qpcfg process.

Users, user groups, and permissions

Minimum authority for all TMTM users, regardless of which group they belong to or what authority they might have, must include display, get, inquire, and put messages from two system-defined queues:

  • SYSTEM.ADMIN.COMMAND.QUEUE
  • SYSTEM.MQSC.REPLY.QUEUE (inquire not needed)

Both of these queues must be explicitly shared on each queue manager.

WebSphere MQ object security grants or denies access to any object based on the permissions accorded to that user and the settings on the object. This enables you to control exactly what users or groups have access to a particular object. With TMTM, you can set those permissions using a graphical interface.

For WebSphere MQ on AIX, HP-UX, HP NonStop Server, Linux, Solaris, and zLinux, you can define different users and groups for security.

Windows behaves differently than UNIX regarding permissions. Users can have permissions in addition to those of the group to which they belong, but permissions cannot be removed from users that are specifically granted by the group to which they belong. For more information, see the IBM WebSphere MQ System Administration Guide.

Note

WebSphere MQ security is set for objects and users at the operating system level, not from TMTM. If you attempt to use TMTM to set WebSphere MQ security on z/OS, an error appears informing you that the feature is not supported.

Logging

If logging is enabled, all security violation messages are logged in the audit log database. The audit log contains a single permanent record of activities between TMTM and WebSphere MQ objects.

Test queues

Minimum authority for all TMTM users, regardless of which group they belong to or what authority they might have, must include display, get, inquire, and put messages from two system-defined queues:

  • SYSTEM.ADMIN.COMMAND.QUEUE
  • SYSTEM.MQSC.REPLY.QUEUE (inquire not needed)

Both of these queues must be explicitly shared on each queue manager.

WebSphere MQ object security grants or denies access to any object based on the permissions accorded to that user and the settings on the object. This enables you to control exactly what users or groups have access to a particular object. With TMTM, you can set those permissions using a graphical interface.

For WebSphere MQ on AIX, HP-UX, HP NonStop Server, Linux, Solaris, and zLinux, you can define different users and groups for security.

Windows behaves differently than UNIX regarding permissions. Users can have permissions in addition to those of the group to which they belong, but permissions cannot be removed from users that are specifically granted by the group to which they belong. For more information, see the IBM WebSphere MQ System Administration Guide.

Note

WebSphere MQ security is set for objects and users at the operating system level, not from TMTM. If you attempt to use TMTM to set WebSphere MQ security on z/OS, an error appears informing you that the feature is not supported.

Logging

If logging is enabled, all security violation messages are logged in the audit log database. The audit log contains a single permanent record of activities between TMTM and WebSphere MQ objects.

WebSphere MQ object security reference

The following examples show how you might use WebSphere MQ object security.

Example 1

A large company relies on WebSphere MQ throughout its organization to transport data to and from queues. This company might have their finance department in England and their manufacturing plant in Germany. The company wants the finance department to be able to create queues in England, but not in the manufacturing plant in Germany. With WebSphere MQ object security, the user in the finance department in England might be able to connect to the queue managers in the manufacturing plant in Germany, however, they do not necessarily have enough privileges to create, delete, clear queues and so on. They are still allowed to create, delete, and clear queues on their own system.

Example 2

A second scenario might involve configuring higher levels of access on test queues versus more restricted access on production queues located on the same queue manager.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*