Stream authority

This topic describes the use of the stream queue when used with publish and subscribe authority checks inWebSphere® MQ Publish/Subscribe.

In WebSphere MQ Publish/Subscribe, all publish and subscribe authority checks are performed against the stream queue:
  • Publishing applications must have the authority to put messages to the stream queue.
  • The WebSphere MQ Publish/Subscribe broker checks the authority of subscribing applications that want to browse the stream queue.
  • Subscribing applications must have the authority to put messages to the queue that it nominated to receive its publications.

A similar check is made by WebSphere Message Broker brokers, but checks are not made for subscribe, or browse, authority. Instead, WebSphere Message Broker uses Access Control Lists (ACLs), which you can create using the workbench, to provide the required authorities for individual topics.

Before you migrate an WebSphere MQ Publish/Subscribe broker to WebSphere Message Broker, or migrate your WebSphere MQ Publish/Subscribe applications to run on a WebSphere Message Broker, you must consider the following security implications:
  • Publishing applications are subject to the same checks even if your broker is not running with topic security enabled, because the authority to put a message to the stream or publication queue continues to be checked by WebSphere MQ.

    However, stream publications can be processed by WebSphere Message Broker on any input queue, because publishers no longer need to put to a queue with the same name as the stream. Therefore, set up equivalent ACLs for all streams using their corresponding topic level qualifiers

  • The WebSphere Message Broker broker does not check that subscribing applications have browse authority on the stream queue. Instead, WebSphere Message Broker models streams by prefixing all topics that are not part of the default stream with a unique prefix, $SYS/STREAM/<streamname>/. This prefix maintains the partitioning characteristics of streams, and also allows stream-specific ACLs to be set up. Because topics in the default stream are not altered by the broker, the root topic can be used to specify authorities for default stream topics.
The following diagram shows the stream authorities that are required. The example assumes that you have updated the default ACL on the topic root for principal PublicGroup with authority for publish, subscribe, and persistent delivery all set to deny.
Stream authorities. The diagram is discussed in the surrounding text.
Using this example, assume that the following groups are defined:
  • PDefault: the group of users that are authorized to publish on the default stream
  • SDefault: the group of users that are authorized to subscribe to the default stream
  • PStreamX: the group of users that are authorized to publish on StreamX
  • SStreamX: the group of users that are authorized to subscribe to StreamX
  • PStreamY: the group of users that are authorized to publish on StreamY
  • SStreamY: the group of users that are authorized to subscribe to StreamY
You must grant and deny authorities by setting up ACLs as follows:
  1. PDefault must be granted publish authority on the root, and SDefault must be granted subscribe authority on the root.
  2. PDefault must be denied publish authority on $SYS/STREAM/, and SDefault must be denied subscribe authority on $SYS/STREAM/.

    These settings ensure that publishers and subscribers on the default stream are unable to publish on, or subscribe to, other streams without an explicit ACL that overrides the relevant setting.

  3. PStreamX must be granted publish authority on $SYS/STREAM/StreamX/, and SStreamX must be granted subscribe authority on $SYS/STREAM/StreamX/.

    These settings override any setting on parent topics and limit publish and subscribe activity to users within these specific groups.

  4. PStreamY must be granted publish authority on $SYS/STREAM/StreamY/, and SStreamY must be granted subscribe authority on $SYS/STREAM/StreamY/.

    These settings override any setting on parent topics and limit publish and subscribe activity to users within these specific groups.

If you want to set up exceptions to this situation, you can do so by introducing an ACL at the appropriate point. For example, if you wanted to grant authority to publishers to the default stream, PDefault, to publish on StreamX, you must create an explicit ACL at point (3) to grant that authority; this setting overrides the denial of authority at point (2). In this scenario, users in PDefault are still unable to publish on StreamY.

Related concepts
Security for runtime resources: Access control lists
Related tasks
Configuring security for domain components
Publishing
Subscribing
Related reference
MQRFH2 header
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Last updated : 2009-01-07 15:22:58

aq19820_