Configure authorization security for the embedded WebSphere JMS provider

Use this task to configure authorization security for the embedded WebSphere JMS provider.

 

Overview

To configure authorization security for the embedded WebSphere JMS provider complete the following steps.

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

1. Configure authorization settings to access JMS resources owned by the embedded WebSphere JMS provider. Authorization to access JMS resources owned by the embedded WebSphere JMS provider is controlled by settings in the WAS_install_root\config\cells\your_cell_name\integral-jms-authorizations.xml file.

   The settings grant or deny authenticated userids access to internal JMS provider resources (queues or topics). As supplied, the integral-jms-authorisations.xml file grants the following permissions:

   • Read and write permissions to all queues.

   • Pub, sub, and persist to all topics.

   To configure authorization settings, edit the integral-jms-authorisations.xml file according to the information in this topic and in that file. Please note the file is in Unicode, which requires a binary FTP to the host from a workstation.

2. Edit the queue-admin-userids element to create a list of userids with administrative access to all queues. Administrative access is needed to create queues and perform other administrative activities on queues.For example, consider the following queue-admin-userids section:

   <queue-admin-userids>
       <userid>adminid1</userid> 
       <userid>adminid2</userid> 
   </queue-admin-userids>
   

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

3. 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 sections). If this section is not specified, then access permissions exist only for those queues for which you have specifically created queue elements.

   For example, consider the following queue-default-permissions element:

     <queue-default-permissions>
       <permission>write</permission>
     </queue-default-permissions>

   In this example the default access permission for all queues is write. This can be overridden for a specific queue by creating a queue element that sets its access permission to read.

4. If you want to define specific access permissions for a queue, create a queue element, then define the following elements:

   For example, consider the following queue 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>

   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 (<public></public>).

5. Edit topic elements to define the access permissions for publish/subscribe topic destinations.

   For topics, you can grant and deny access permissions. Full permission inheritance is supported on 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 until the root topic from which the root permissions are assumed.

   1. If you want to define default access permissions for the root topic, edit a topic element with an empty name element. If you omit such a topic section, topics have no default topic permissions other than those defined by specific topic elements.For example, consider the following topic element for the root topic:

       <topic>
          <name></name>
          <public>
            <permission>+pub</permission>
          </public>
        </topic>

      In this example, the default access permission for all topics is set to publish. This can be overridden by other topic elements for specific topic names.

   2. If you want to define access permissions for a specific topic, create a topic element with the name for the topic then define the access permissions in the public and authorize elements of the topic element. For example, consider the following topic section:

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

      In this example, the subscribe permission is granted to anyone accessing any topic whose name starts with a/b/c. Also, the userid useridpub is granted publish permission for any topic whose name starts with a/b/c.

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

 

Results

If the dynamic update setting is selected, changes to the integral-jms-authorizations.xml file become active when the changed file is saved, so there is no need to stop and restarted the JMS server. If the dynamic update setting is not selected, you need to stop and restart the JMS server to make changes active.

---

Asynchronous messaging - security considerations

Managing JMS servers on an Application Server node
Managing JMS servers in a deployment manager cell
Configuring JMS provider resources
Administering WebSphere JMS support

Authorization settings for embedded WebSphere JMS provider resources
    

 

---