The OAM provides a command interface for granting and revoking authority to WebSphere MQ objects. You must be suitably authorized to use these commands, as described in Authority to administer WebSphere MQ. User IDs that are authorized to administer WebSphere MQ have super user authority to the queue manager, which means that you do not have to grant them further permission to issue any MQI requests or commands.
Queue managers running the OAM store authorization data on a local queue, called SYSTEM.AUTH.DATA.QUEUE. Authorization data is managed by the amqzfuma process (amqzfuma.exe for Windows systems).
Use the setmqaut command to give users, and groups of users, access to WebSphere MQ objects. For a full definition of the command and its syntax, see setmqaut (set or reset authority). The queue manager must be running to use this command. When you have changed access for a principal, the changes are reflected immediately by the OAM.
To give users access to an object, you need to specify:
If a user ID contains spaces, enclose it in single quotes when you use this command. On Windows systems, you can qualify a user ID with a domain name. If the actual user ID contains an @ symbol, replace this with @@ to show that it is part of the user ID, not the delimiter between the user ID and the domain name.
You can specify any number of authorizations in a single command. For example, the list of authorizations to permit a user or group to put messages on a queue and to browse them, but to revoke access to get messages is:
+browse -get +put
The following examples show how to use the setmqaut command to grant and revoke permission to use an object:
setmqaut -m saturn.queue.manager -t queue -n RED.LOCAL.QUEUE -g groupa +browse -get +put
In this example:
The following command revokes put authority on the queue MyQueue from principal fvuser and from groups groupa and groupb. On UNIX systems, this command also revokes put authority for all principals in the same primary group as fvuser.
setmqaut -m saturn.queue.manager -t queue -n MyQueue -p fvuser -g groupa -g groupb -put
If you are using your own authorization service instead of the OAM, you
can specify the name of this service on the setmqaut command to
direct the command to this service. You must specify this parameter if
you have multiple installable components running at the same time; if you
do not, the update is made to the first installable component for the
authorization service. By default, this is the supplied OAM.
OAM generic profiles enable you to set the authority a user has to many
objects at once, rather than having to issue separate setmqaut
commands against each individual object when it is created. Using
generic profiles in the setmqaut command enables you to set a
generic authority for all future objects created that fit that profile.
The rest of this section describes the use of generic profiles in more
detail:
What makes a profile generic is the use of special
characters (wildcard characters) in the profile name. For example, the
? wildcard character matches any single character in a name. So, if you
specify ABC.?EF, the authorization you give to that profile
applies to any objects created with the names ABC.DEF,
ABC.CEF, ABC.BEF, and so on.
The wildcard characters available are:
For example, ABC.*.JKL would apply to the objects
ABC.DEF.JKL, and
ABC.GHI.JKL. (Note that it would
not apply to ABC.JKL; * used in this context
always indicates one qualifier.)
For example, ABC.DE*.JKL would apply to the
objects ABC.DE.JKL,
ABC.DEF.JKL, and
ABC.DEGH.JKL.
An important point to understand when using generic
profiles is the priority that profiles are given when deciding what
authorities to apply to an object being created. For example, suppose
that you have issued the commands:
The first gives put authority to all queues for the principal fred with
names that match the profile AB.*; the second gives get authority
to the same types of queue that match the profile AB.C*.
Suppose that you now create a queue called AB.CD. According
to the rules for wildcard matching, either setmqaut could apply to that
queue. So, does it have put or get authority?
To find the answer, you apply the rule that, whenever multiple profiles can
apply to an object, only the most specific applies. The way
that you apply this rule is by comparing the profile names from left to
right. Wherever they differ, a non-generic character is more specific
then a generic character. So, in the example above, the queue
AB.CD has get authority (AB.C* is more specific than
AB.*).
When you are comparing generic characters, the order of
specificity is:
The dmpmqaut command enables you to dump the current
authorizations associated with a specified profile.
The following examples show the use of dmpmqaut to dump authority records
for generic profiles:
The resulting dump would look something like this:
The resulting dump would look something like this:
The resulting dump would look something like this:
The resulting dump would look something like this:
The resulting dump would look something like this:
Using OAM generic profiles
Using wildcard characters
Note: When using wildcard characters on UNIX systems, you must enclose
the profile name in quotes.
Profile priorities
setmqaut -n AB.* -t q +put -p fred
setmqaut -n AB.C* -t q +get -p fred
Dumping profile settings
dmpmqaut -m qm1 -n a.b.c -t q -p user1
profile: a.b.*
object type: queue
entity: user1
type: principal
authority: get, browse, put, inq
dmpmqaut -m qmgr1 -n a.b.c -t q
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
dmpmqaut -m qmgr1 -n a.b.* -t q
profile: a.b.*
object type: queue
entity: user1
type: principal
authority: get, browse, put, inq
dmpmqaut -m qmX
profile: q1
object type: queue
entity: Administrator
type: principal
authority: all
- - - - - - - - - - - - - - - - -
profile: q*
object type: queue
entity: user1
type: principal
authority: get, browse
- - - - - - - - - - - - - - - - -
profile: name.*
object type: namelist
entity: user2
type: principal
authority: get
- - - - - - - - - - - - - - - - -
profile: pr1
object type: process
entity: group1
type: group
authority: get
dmpmqaut -m qmX -l
profile: q1, type: queue
profile: q*, type: queue
profile: name.*, type: namelist
profile: pr1, type: process
For detailed information on the command, see dmpmqaut (dump authority).
Note: For WebSphere MQ for Windows only, all principals displayed include domain
information, for example:
profile: a.b.*
object type: queue
entity: user1@domain1
type: principal
authority: get, browse, put, inq
Use the dspmqaut command to view the authorizations that a specific principal or group has for a particular object. The queue manager must be running to use this command. When you change access for a principal using setmqaut, the changes are reflected immediately by the OAM. The flags have the same meaning as those in the setmqaut command. Authorization can be displayed for only one group or principal at a time. See dspmqaut (display authority) for a formal specification of this command.
For example, the following command displays the authorizations that the group GpAdmin has to a process definition named Annuities on queue manager QueueMan1.
dspmqaut -m QueueMan1 -t process -n Annuities -g GpAdmin
To change the level of access that a user or group has to an object, use the setmqaut command. To revoke the access of a particular user that is a member of a group that has authorization, remove the user from the group, as described in Creating and managing groups.
The user ID that creates a WebSphere MQ object is granted full control authorities to that object. If you remove this user ID from the local mqm group (or the Administrators group on Windows systems) these authorities are not revoked. Use the setmqaut command to revoke access to an object for the user ID that created it, after removing it from the mqm or Administrators group.
If you decide that you do not want to perform security checks (for example, in a test environment), you can disable the OAM in one of two ways:
On Windows systems:
SET MQSNOAUT=yes
On UNIX systems:
export MQSNOAUT=yes