Configure authorization security for a V5 default messaging provider

 

Use this task to configure authorization security for the default messaging provider on a WAS V5 node in a deployment manager cell.

 

Overview

To configure authorization security for the V5 default messaging provider complete the following steps.

Security for the V5 default messaging provider is enabled when you enable WAS security on the V5 node. For more information about enabling security, see Enabling security.

 

Procedure

1. Configure authorization settings to access JMS resources owned by the embedded messaging subsystem. Authorization to access JMS resources owned by the embedded messaging subsystem is controlled by settings in the app_server_root\config\cells\your_cell_name\integral-jms-authorizations.xml file. The settings grant or deny authenticated users access to messaging 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. 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. 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. 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, stop and restart the JMS server to make changes active.

---

Authorization settings for V5 default JMS resources

 

Related concepts

Asynchronous messaging - security considerations

 

Related tasks

Manage V5 JMS servers in a deployment manager cell
Use JMS resources of a generic provider