Enabling topic-based security

If your applications use the publish/subscribe services of a broker, you can apply an additional level of security to the topics on which messages are published and subscribed. This topic-based security is managed by the User Name Server.

Complete the following steps:

  1. Before you create a User Name Server, refer to Considering security for a User Name Server.
  2. Create a User Name Server. Refer to Creating a User Name Server.
  3. Select the -j flag and set the -s parameter to the name of the queue manager for the User Name Server on the mqsicreatebroker or mqsichangebroker command.
  4. Set the -s parameter on the mqsicreateconfigmgr or mqsichangeconfigmgr command to the name of the queue manager for the User Name Server.
  5. Create ACLs for the topics that require additional security. For more information, see Creating ACL entries.
  6. Ensure that the broker's service user ID has authority to:
    1. Get messages from each input queue included in a message flow
    2. Put messages to any output, reply, and failure queues included in a message flow.
  7. Ensure that the user IDs under which publish and subscribe applications run have sufficient authority to put to and get from message flow queues:
    1. Authorize publish applications to put messages to the input queue of the message flow.
    2. Authorize applications that register subscriptions to put to the SYSTEM.BROKER.CONTROL.QUEUE queue.
    3. Authorize subscribe applications to get from the queue to which messages are published.
    4. Authorize publish and subscribe applications to get from the reply queue.

If you are issuing publish/subscribe requests from a JMS client, additional security options are available. Refer to SSL authentication, Quality of protection, and Authentication services.

Go to Considering security for a Configuration Manager.

Considering security for a User Name Server

Complete this task by answering the following question:
Have you enabled topic-based security in your broker?
  1. No: Go to Considering security for a Configuration Manager.
  2. Yes: You need a User Name Server. Go to Deciding which user accounts can execute User Name Server commands.

Deciding which user accounts can execute User Name Server commands

During this task you decide what permissions are required for the user IDs that:
  • Create, change, list, delete, start, and stop a User Name Server
  • Display, retrieve, and change trace information.

Answer the following questions:

  1. Is your User Name Server installed on a Linux or UNIX operating system?
    1. No: Go to the next question.
    2. Yes: The information about executing User Name Server commands on Linux and UNIX is not yet available.

      Go to Deciding which user account to use for the User Name Server service ID.

  2. Are you executing User Name Server commands under a Windows local account?
    1. No: Go to the next question.
    2. Yes: Assume that your local account is on a computer named, for example, WKSTN1. When you create a User Name Server, ensure that your user ID is defined in your local domain. When you create or start a User Name Server, ensure that your user ID is a member of WKSTN1\Administrators.

      Go to Deciding which user account to use for the User Name Server service ID.

  3. Are you executing User Name Server commands under a Windows domain account?
    1. Yes: Assume that your computer named, for example, WKSTN1, is a member of a domain named DOMAIN1. When you create a User Name Server using, for example, DOMAIN1\user1, ensure that DOMAIN1\user1 is a member of WKSTN1\Administrators.

      Go to Deciding which user account to use for the User Name Server service ID.

Deciding which user account to use for the User Name Server service ID

When you set the service ID with the -i option on the mqsicreateusernameserver or mqsichangeusernameserver command, you determine the user ID under which the User Name Server component process runs.

Answer the following questions:

  1. Is your User Name Server installed on a Linux or UNIX operating system?
    1. No: Go to the next question.
    2. Yes: The information about running your User Name Server on Linux and UNIX is not yet available.

      Go to Setting security on the User Name Server's queues

  2. Do you want your User Name Server to run under a Windows local account?
    1. No: Go to the next question.
    2. Yes: Ensure that your user ID is defined in your local domain and is a member of mqbrkrs.

      Go to Setting security on the User Name Server's queues

  3. Do you want your User Name Server to run under a Windows domain account?
    1. Yes: Assume that your computer named, for example, WKSTN1, is a member of a domain named DOMAIN1. When you run a User Name Server using, for example, DOMAIN1\user1, ensure that:DOMAIN1\user1 is a member of DOMAIN1\Domain mqbrkrs and DOMAIN1\Domain mqbrkrs is a member of WKSTN1\mqbrkrs.

      Go to Setting security on the User Name Server's queues.

Setting security on the User Name Server's queues

When you run the mqsicreateusernameserver command, the mqbrkrs group gets access authority to the following queues:
  • SYSTEM.BROKER.SECURITY.QUEUE
  • SYSTEM.BROKER.MODEL.QUEUE
Only the broker and the Configuration Manager require access to the User Name Server's queues.

Running the User Name Server in a domain environment

When the users that issue publish and subscribe commands are domain users, set the -d option on the mqsicreateusernameserver command to the domain those users come from. All users that issue publish and subscribe commands must come from the same domain.