Use this task to configure authorization security for the embedded WebSphere JMS provider.
Why and when to perform this task
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.
Steps for this task
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:
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.
<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.
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.
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>).
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.
<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.
<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.
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.