WAS v8.5 > WebSphere applications > Service integration > Service integration security
Topic security
Client applications publish and subscribe to a topic. When messaging security is enabled, client applications require authority to access a topic.
Topics are contained within a topic space, which is a type of destination. Within the topic space, topics are organized into one or more topic hierarchies, based on the topic names. The topic hierarchies are joined to a virtual root that is created when the topic space is created. A topic is created within the topic space when a client application publishes to the topic.
When a connection accesses a topic, an access check is performed to ensure the user associated with the connection has permission to access the topic space destination containing the topic. A second check is performed to ensure 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 later in this section. The diagram shows a topic space called tspace1 containing two topic hierarchies, called sports, and cars.
Figure 1. Example of a topic space with topic-level authorization
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.
Each bus can contain more than one topic space. Each topic space is independent of other topic spaces on the bus. Topics in separate topic spaces are not related, even if they have the same name. Consider, for example, a bus containing two topic spaces called tspace1 and tspace2, and each topic space contains a topic called cars. If a client application subscribes to cars in tspace1, it can only receive messages published to the cars topic in tspace1.
Role-based authorization and topic inheritance
Topic security is based on role-based authorization. For further information, see Role-based authorization. To make it easier to administer security authorization for a large number of topics, the access role defined for a topic contains the access authority for the topic itself and, by default, for any topic beneath it within the topic hierarchy. A topic therefore inherits roles from the parent topic. An access role defined on the virtual root therefore contains, by default, access authority for every topic in the topic space. In the example given above, the sender and receiver roles have been defined on the virtual root of topic space tspace1.
We can define new roles for a topic, and we can disable topic role inheritance for any topic in the topic hierarchy. New roles are added to any roles the topic inherits from its parent topic. The figure above contains the following examples of how topic role inheritance works:
- The topics sports, cricket and cars topics inherit the sender role defined on the virtual root, but inheritance of the sender role for the topic tennis is disabled. This means the topic tennis and its children cannot inherit the sender role from the virtual root. The sender role is defined for the topic tennis itself. The messaging engine checks that a connecting client application has authority in the sender role for the topic tennis and its children.
- Every topic in the hierarchy inherits the receiver role from the virtual root. The sports topic also has its own receiver role. The messaging engine performs additional checks where additional access roles exist. The children of the topic sports inherit the receiver role from the parent topic, and from the virtual root. The lawn topic also has its has its own receiver role.
We can define access roles for a topic before the topic is created at runtime. Note the topic can inherit roles from its parent unless you explicitly disable topic inheritance.
Subscription authorization
When a client application creates a subscription for a selected topic, the messaging engine checks the client has authority in the receiver role to receive messages published to the selected topic. A subscription can be for a single topic, or using wild cards in the topic specification, for multiple topics. In either case, when a message arrives for the subscription, the messaging engine checks the client application has authority in the receiver role for the selected topic. When a client application creates a subscription for a single topic, the messaging engine checks the client has authority in the creator role to create a subscription.
A non-durable subscription exists for the duration of the subscriber session. This means the subscription ceases to exist when the subscriber session ends. A durable subscription continues to exist after the subscriber session ends. This means the subscription continues to collect messages on the topic or topics when the subscriber is not connected to the bus. The subscriber can restart the subscription, and collect the messages. Only the client application that created the durable subscription can restart it. This allows the messaging engine to check for access authority for messages that are collected on the topic when the subscription is inactive.
Related concepts:
Bus destinations
Role-based authorization
Publish/subscribe messaging and topic spaces
Related
Administer destination roles
Secure service integration
Administer topic space root roles
Administer topic roles
Create a topic space for publish/subscribe messaging
Reference:
Access role assignments for bus security resources
Define topic role inheritance using wsadmin
Determine topic role inheritance using wsadmin