Authorization settings for Version 5 default JMS resources

Use the integral-jms-authorisations.xml file to view or change the authorization settings for Java Message Service (JMS) resources owned by the default messaging provider on WebSphere Application Server Version 5 nodes.

Authorization to access default JMS resources owned by the default messaging provider on WebSphere Application Server nodes is controlled by the following settings in the wempspath/wempsname/config/integral-jms-authorizations.xml file.

This structure of the settings in integral-jms-authorisations.xml is shown in the following example. Descriptions of these settings are provided after the example. To configure authorization settings, follow the instructions provided in Configuring authorization security for the Version 5 JMS providers
<integral-jms-authorizations>

  <dynamic-update>true</dynamic-update>

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

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

  <queue>
    <name>q1</name>
    <public>
    </public>
    <authorize>
      <userid>useridr</userid>
      <permission>read</permission>
    </authorize>
    <authorize>
      <userid>useridw</userid>
      <permission>write</permission>
    </authorize>
  </queue>

  <queue>
    <name>q2</name>
    <public>
      <permission>write</permission>
    </public>
    <authorize>
      <userid>useridr</userid>
      <permission>read</permission>
    </authorize>
  </queue>

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

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

</integral-jms-authorizations>

dynamic-update

Controls whether or not the JMS Server checks dynamically for updates to this file.
true
(Default) Enables dynamic update support.
false
Disables dynamic update checking and improves authorization performance.

queue-admin-userids

This element lists those userids with administrative access to all Version 5 default queue destinations. Administrative access is needed to create queues and perform other administrative activities on queues. You define each userid within a separate userid sub element:
<userid>adminid</userid>
Where adminid is a user ID that can be authenticated by IBM WebSphere Application Server.

queue-default-permissions

This element defines the default queue access permissions that are assumed if no permissions are specified for a specific queue name. These permissions are used for queues for which you do not define specific permissions (in queue elements). If this element is not specified, then no access permissions exist unless explicitly authorized for individual queues.

You define the default permission within a separate permission sub element:
<permission>read-write</permission>
Where read-write is one of the following keywords:
read
By default, userids have read access to Version 5 default queue destinations.
write
By default, userids have write access to Version 5 default queue destinations.

queue

This element contains the following authorization settings for a single queue destination:

name
The name of the queue.
public
The default public access permissions for the queue. This is used only for those userids that have no specific authorize element. If you leave this element empty, or do not define it at all, only those userids with authorize elements can access the queue.

You define each default permission within a separate permission element.

authorize
The access permissions for a specific userid. Within each authorize element, you define the following elements:
userid
The userid that you want to assign a specific access permission.
permission
An access permission for the associated userid.

You define each permission within a separate permission element. Each permission element can contain the keyword read or write to define the access permission.

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>

topic

This element contains the following authorization settings for a single topic destination:

Each topic element has the following sub elements:

name
The name of the topic, without wildcards or other substitution characters.
public
The default public access permissions for the topic. This is used only for those userids that have no specific authorize element. If you leave this element empty, or do not define it at all, only those userids with authorize elements can access the topic.

You define each default permission within a separate permission element.

authorize
The access permissions for a specific userid. Within each authorize element, you define the following elements:
userid
The userid that you want to assign a specific access permission.
permission
An access permission for the associated userid.
You define each permission within a separate permission element. Each permission element can contain one of the following keywords to define the access permission:
+pub
Grant publish permission
+sub
Grant subscribe permission
+persist
Grant persist permission
-pub
Deny publish permission
-sub
Deny subscribe permission
-persist
Deny persist permission



Related tasks
Configuring authorization security for a Version 5 default messaging provider
Reference topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 8:25:23 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-zos&topic=umj_padmsw
File name: umj_padmsw.html