+

Search Tips   |   Advanced Search

Authorization settings for V5 default JMS resources

Use the integral-jms-authorisations.xml file to view or change the authorization settings for JMS resources owned by the default messaging provider on WAS Version 5 nodes.

Authorization to access default JMS resources owned by the default messaging provider on WAS nodes is controlled by the following settings in the was_install\config\cells\your_cell_name\integral-jms-authorisations.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 V5 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 V5 default queue destinations.

write

By default, userids have write access to V5 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 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 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


Configure authorization security for the embedded WebSphere JMS provider

 

Reference topic