CODEWITHSUNDEEP
ibm-mq
arrehman
arrehman

Reputation: 1322

WebSphere MQ Recommended AUTHRECS

What would be the recommended values for AUTHRECS for the following,of course this needs to be tweaked per one's requirements.

  1. QUEUE MANAGER
  2. QUEUE (local, remote, dlq)
  3. CHANNEL (server connection, sender, receiver etc.)

Upvotes: 2

Views: 286

Answers (1)

T.Rob
T.Rob

Reputation: 31832

I usually tell people to consider three different groups for security:

  1. QMgr-to-QMgr connections which boil down to "what auths do I grant the MCAUSER of a RCVR/RQSTR/CLUSRCVR channel?" The roles in this category depend on how granular you want network security to be. In general though, the adjacent QMgrs should NOT have access to the local QMgr's command queues. The channel's MCAUSER gets to connect to the QMgr and inquire, then put and setall on the queues it actually needs. That's it.
  2. Application-to-QMgr. By "application" here I mean a business application residing in a locked data center. These applications generally need to connect and inquire on the QMgr and then put, get, browse, publish, subscribe on queues and topics. Sometimes they need more elevated auths like the ability to set the context info for a message, but that is rare and limited to specific queues.
  3. Interactive users. Among this group there are various roles such as administrator, anonymous user and everything in between. These may need access to display or even manage objects other than queues and topics.

Each of these has very different authentication and authorization requirements. They also have different characteristics such as the volume of messages and stability of the accounts and authorizations they require.

They do all have a few things in common, though.

  • Granting set on the QMgr to anyone with access to the command queue makes them a full administrator.
  • Granting the ability to create queues (other than dynamic ones) makes the user a full administrator.
  • Anything that connects or opens an object needs inquire on the QMgr and objects it is authorized to.
  • Business applications need read/write access to their queues and topics but not other types of objects.
  • Instrumentation generally needs access to many object types but not to read or update the messages on the business queues.
  • Human users need at least display access to all objects if you are monitoring security. This is because the only way to enumerate objects (for example to paint a queues screen) is to do the PCF equivalent of DIS objType(*). If the user doesn't have display access to all objects of objType then the QMgr emits authorization errors when the display is issued.

Upvotes: 2

Related Questions