Configure authorization security for the embedded WebSphere JMS provider

Authorization to access JMS resources owned by the embedded WebSphere JMS provider is controlled by settings in the integral-jms-authorizations.xml file. This file is located in the /QIBM/UserData/WebAS5/Base/instance/config/cells/cell directory, where instance is the name of your instance and cell is the name of your cell.

The settings in this file grant or deny authenticated userids access to embedded JMS queues and topics. By default, the integral-jms-authorizations.xml file grants these permissions:

For more information, see Authorization settings for embedded WebSphere JMS provider resources. Go to Help documentation

Note: Security for the embedded WebSphere JMS provider is enabled when you enable global security for WebSphere Application Server. For more information, see Configure global security.

To configure authorization security for the embedded WebSphere JMS provider, follow these steps:

  1. Edit the queue-admin-userids element to create a list of userids with administrative access to all queues. Administrative access is needed to create and manage queues.

    In this example the userids adminid1 and adminid2 are defined to have administrative access to all queues:

    <queue-admin-userids>
      <userid>adminid1</userid>
      <userid>adminid2</userid>
    </queue-admin-userids>
  2. Edit the queue-default-permissions element to define the default queue access permissions. These permissions are used for queues for which you do not define specific permissions (in queue elements). To override the default permission, create a queue element that sets its access permission to read. If this element is not specified, then access permissions exist only for those queues for which you have specifically created queue elements.

    In this example the default access permission for all queues is write:

    <queue-default-permissions>
      <permission>write</permission>
    </queue-default-permissions>
  3. To define specific access permissions for a queue, create a queue element, then define the name, public, and authorize elements for the queue.

    In this example for the queue q1, the userid useridr has read permission, the userid useridw has write permission, the userid useridrw has both read and write permissions, and all other userids have no access permissions (specified by the public element):

    <queue>
      <name>q1</name>
      <public></public>
      <authorize>
        <userid>useridr</userid>
        <permission>read</permission>
      </authorize>
      <authorize>
        <userid>useridw</userid>
        <permission>write</permission>
      </authorize>
      <authorize>
        <userid>useridrw</userid>
        <permission>read</permission>
        <permission>write</permission>
      </authorize>
    </queue>
  4. Edit topic elements to define the access permissions for publish/subscribe topic destinations.

    Full permission inheritance is supported for JMS topics. If you do not define specific access permissions for a userid on a specific topic then permissions are inherited first from the public permissions on that topic then from the parent topic. The inheritance of access permissions continues to the root topic from which the root permissions.

    • To define default access permissions for the root topic, edit a topic element with an empty name element. If you omit such a topic element, topics have no default topic permissions other than those defined by specific topic elements.

      In this example, the default access permission for the root topic is set to publish. By default, this access permission is inherited by all other topics. To override the default permission, define permissions for a specific topic.

      <topic>
        <name></name>
        <public>
          <permission>+pub</permission>
        </public>
      </topic>
    • To define access permissions for a specific topic, create a topic element, then defint the name, public, and authorize elements for the topic.

      In this example, permissions are defined for all topics with names that begin with a/b/c. All users have subscribe permission, and useridpub is granted publish permission for any topic whose name starts with a/b/c.

      <topic>
        <name>a/b/c</name>
        <public>
          <permission>+sub</permission>
        </public>
        <authorize>
          <userid>useridpub</userid>
          <permission>+pub</permission>
        </authorize>
      </topic>

  5. Save the integral-jms-authorizations.xml file.

If the dynamic update setting is selected, changes to the integral-jms-authorizations.xml file become active when the changed file is saved. You do not need to stop and restart the JMS server. If the dynamic update setting is not selected, stop and restart the JMS server to apply your changes.