WebSphere WebSphere Application Server Version 6.1.x Feature Pack for Web Services Operating Systems: AIX, HP-UX, i5/OS, Linux, Solaris, Windows, z/OS

Topic security

When messaging security is enabled, users must be authorized to access topics.

Topics are contained in a topic space, which is one of the types of destination. Within the topic space, topics are organized into hierarchies based on the topic names. There can be more than one topic hierarchy within a topic space, and they are all joined to a "virtual root" which is created when the topic space is created. After the topic space has been created, topics can be created within it simply by publishing on them.

When a connection accesses a topic, an access check is performed to ensure that the user associated with the connection has permission to access the topic space destination that contains the topic. A second check is performed to ensure that the user also has access to the topic itself, within the topic hierarchy owned by the topic space destination. This allows for finer-grained control of access to topics, as shown in the diagram below. The diagram shows a topic space called tspace1 which contains two topic hierarchies, called sports, and cars.

Figure 1. Example of a topic space with topic-level authorization
This figure shows an example of a topic space with topic-level authorization. Topic space tspace1 has two topic hierarchies, sports and cars, and has a Sender and Receiver role defined on the virtual root, with additional roles defined on tasks at various levels in the sports hierarchy. The inheritance of defaults is blocked in one branch of the sports hierarchy.
Note: A connection must have authority to access the topic space destination, regardless of any access it has been granted within the topic hierarchy owned by that topic space destination.

To make the authorization permissions easier to manage when there is a large number of topics, a role (see Role-based authorization) defined on a topic contains permissions for the topic itself and also, by default, for any topics that descend from it in the hierarchy, that is, a topic inherits roles from its parent topic. It follows that a role defined on the virtual root contains, by default, permissions for all of the topics in the topic space. In the above example, these permissions are contained in the Sender and Receiver roles defined on the virtual root of tspace1.

If required, you can define new roles or disallow role inheritance for any topic in the hierarchy.

For example, in the diagram above:

A topic does not need to exist when you define roles for it, you can define the roles before the topic itself is created at runtime. If you do define roles for a topic, it will still inherit roles from its parent unless you explicitly block the inheritance.

There can be more than one topic space within a bus. Each topic space is completely separate from any others, and topics in different topic spaces are not related even if they have the same name. So, for example, if topic space tspace1 and topic space tspace2 both contained a cars topic, but you just subscribed to the topic in tspace1, you would only be able to receive messages published to the cars topic in tspace1, and not to the cars topic in tspace2.

Related concepts
Role-based authorization
Publish/subscribe messaging and topic spaces
Related tasks
Learning about bus destinations
Administering destination roles through the command line
Administering messaging security
Administering topic space root roles through the command line
Administering topic roles through the command line
Creating a topic space for publish/subscribe messaging

Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 27 November 2008
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.wsfep.multiplatform.doc/concepts/cjr0440_.html

Copyright IBM Corporation 2004, 2008. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)