Topic-based security

Use topic-based security to control which applications in your publish/subscribe system can access information on which topics.

For each topic to which you want to restrict access, you can specify which principals (user IDs and groups of user IDs) can publish to the topic, and which principals can subscribe to the topic. You can also specify which principals can request persistent delivery of messages.

Any principal can publish, subscribe, and request persistent delivery of, messages on any topic whose access you do not explicitly restrict.

Topic-based security is managed by a User Name Server that uses the access control lists (ACLs) that you create to decide which authorizations are applied.

Principals and the User Name Server

The User Name Server in WebSphere Message Broker manages the set of principals that are already defined in your network, on behalf of the brokers and the Configuration Manager, for use in publish/subscribe. On Windows, this list of users is taken from the domain specified on the mqsicreateusernameserver command.

The User Name Server is made known to both the broker and the Configuration Manager by specifying the User Name Server queue manager on the mqsicreatebroker and mqsicreateconfigmgr commands.

Message brokers within the broker domain interact with the User Name Server to retrieve the total set of users and groups from which the access control lists are built and against which the publish/subscribe requests are validated. The Configuration Manager interacts with the User Name Server to display the users and user groups in the ACLs that are created using the Topics Hierarchy Editor that is provided in the Broker Administration perspective of the workbench.

Access control lists

Access control lists are used to define, for any topic and principal, the right of that principal to publish on, or subscribe to, that topic, or to request persistent delivery of a publication on that topic.

You can also use the ACL to define the level of message protection that you want to apply to each topic.

Specify these definitions using the Topics Hierarchy Editor in the Broker Administration perspective of the workbench.

Access control can be set explicitly for each individual topic. However, if no explicit ACL is defined for a topic, access control is inherited from an ancestor or parent topic, as defined by the hierarchical structure of the topic tree. If no topic in the hierarchy up to the topic root has an explicit ACL, the topic inherits the ACL of the topic root.

Any defined principal that is known to the User Name Server can be associated with a topic in this way.

Resolving ACL conflicts

If the principals in your broker domain include one or more users in more than one group, the explicit or inherited ACL values might conflict. The following rules indicate how a conflict is resolved:
  • If the user has an explicit user ACL on the topic of interest, this always takes priority and the broker verifies the current operation on that basis.
  • If the user does not have an explicit user ACL on the topic of interest, but has explicit user ACLs against an ancestor in the topic tree, the closest ancestor ACL for that user takes priority and the broker verifies the current operation on that basis.
  • If there are no explicit user ACLs for the user on the topic of interest or its ancestors, the broker attempts to verify the current operation on the basis of group ACLs:
    • If the user is a member of a group that has an explicit group ACL on the topic of interest, the broker verifies the current operation on the basis of that group ACL.
    • If the user is not a member of a group that has an explicit group ACL on the topic of interest, but is a member of a group with explicit group ACLs against an ancestor in the topic tree, the closest ancestor ACL takes priority and the broker verifies the current operation on that basis.
    • If, at a particular level in the topic tree, the user ID is contained in more than one group with an explicit ACL, permission is granted if any of the specifications are positive; otherwise it is denied.

You cannot associate ACLs with topics that include one or more wildcard characters. However, access from your client application is resolved correctly when the subscription registration is made, even when that application specifies a wildcard character in the topic.

PublicGroup authorizations

In addition to the groups that you define, WebSphere Message Broker provides an implicit group, PublicGroup, to which all users automatically belong. This implicit group simplifies the specification of ACLs in a topic tree. In particular, this group is used in the specification of the ACL for the topic root. Note that the default setting of the topic root allows publish and subscribe operations for the PublicGroup. You can view and change this ACL using the workbench, but you cannot remove it. It determines the default permissions for the entire topic tree. You can specify ACLs for the PublicGroup elsewhere in the topic tree, wherever you want to define permissions for all users.

If you have a principal named Public defined in your existing security environment, you cannot use this for topic-based security. If you specify this principal within an ACL, it is equated to PublicGroup and therefore always allows global access.

mqbrkrs authorizations

WebSphere Message Broker grants special publish/subscribe access control privileges to members of the mqbrkrs group, and to the corresponding Domain mqbrkrs global group if appropriate.

Brokers need special privileges to perform internal publish and subscribe operations in networks where there is access control. When you create a broker in such a network, you must specify a user ID that belongs to the group mqbrkrs as the service user ID for the broker. The mqbrkrs group is given implicit privileges so that its members can publish, subscribe and request the persistent delivery of messages on the topic root (""). All other topics inherit these permissions. If you attempt to configure an ACL for the mqbrkrs group using the workbench, this ACL is ignored by WebSphere Message Broker.

ACLs and system topics

Messages that are used for internal publish and subscribe operations are published throughout the broker domain using system topics, which begin with the strings "$SYS" and "$ISYS".

These topics can only published from, and subscribed to, members of the mqbrkrs group, except for the following two scenarios:
  1. If you are migrating topics from WebSphere MQ Publish/Subscribe, you can configure ACLs on topics that begin with the string "$SYS/STREAM".
  2. Clients can subscribe to topics that begin with the string "$SYS"; this means that applications that provide a management function can subscribe to the broker for administrative events.

Do not configure ACLs on topics that begin with the string "$ISYS". You are not prevented from doing so, but the ACLs are ignored.

Setting access control on topics

Any user that has an object-level security ACL that gives full control permission to the root topic object, can define and manipulate the ACLs that define which principals can publish on, and subscribe to, which topics. ACLs can also limit delivery of persistent messages, and define the level of message protection.

All defined principals can be associated with any topic; the permissions that can be set are shown in the following table:
Option Description
Publish Permits or denies the principal to publish messages on this topic.
Subscribe Permits or denies the principal to subscribe to messages on this topic.
Persistent Specifies whether the principal can receive messages persistently. If the principal is not permitted, all messages are sent non-persistently. Each individual subscription indicates whether the subscriber requires persistent messages.
QoP Level Specifies the level of message protection that is enforced. One of the following four values can be chosen:
  • None
  • Channel Integrity
  • Message Integrity
  • Encrypted
The default value is 'None'.
Persistent access control behavior is not identical to the publish and subscribe control:
  • Clients that are denied Publish access have their publication messages refused.
  • Clients that are denied Subscribe access do not receive the publication.
  • The persistent access control does not deny the message to subscribers, but denies them persistence, so denied subscribers always receive messages, subject to their subscribe access control, but always have the message sent to them non-persistently, regardless of the persistence of the original message.

Inheritance of security policies

Typically, topics are arranged in a hierarchical tree. The ACL of a parent topic can be inherited by some or all of its descendent topics that do not have an explicit ACL. Therefore, it is not necessary to have an explicit ACL associated with each and every topic. Every topic has an ACL policy which is that of its parent. If all parent topics up to the root topic do not have explicit ACLs, that topic inherits the ACL of the root topic.

For example, in the topic tree shown below, the topic root is not shown but is assumed to have an ACL for PublicGroup whose members can publish, subscribe, and receive persistent publications. (The symbol "¬" means "not".)

Inheriting ACLs in a topic tree


The figure shows a topic tree with the following structure. A is the top level, with B, K and P at the next level. From K there are further levels with nodes M and then N. For some of the nodes in the tree, ACLs are shown.Node A has a Publish ACL containing joe, a Subscribe ACL containing Public Group, and a Persistent ACL containing ¬Public Group.Node B has a Publish ACL containing allen, and a Subscribe ACL containing HR and ¬Public Group. There is no explicitly defined Persistent ACL.Node P has a Publish ACL containing joe, no explicitly defined Subscribe ACL, and a Persistent ACL containing joe.Node N has a Publish ACL containing mary and joe, a Subscribe ACL containing nat, and a Persistent ACL containing Public Group and ¬nat.Nodes K and M have no explicitly defined ACLs.
The following table shows the ACLs, inherited in some cases, that result from the topic tree shown in the figure:
Topic Publishers Subscribers Persistent
A only joe everyone no-one
A/P only joe everyone only joe
A/K only joe everyone no-one
A/K/M only joe everyone no-one
A/K/M/N only mary, joe everyone everyone except nat
A/B allen, joe HR no-one

Dynamically created topics

Topics that are not explicitly created by the system administrator, but are created dynamically when a client publishes or subscribes to messages, are treated in the same way as those that are created by the system administrator, but they do not have explicitly defined ACLs. That is, the ACLs for dynamically created topics are inherited from the closest ancestor in the topic tree that has an explicit policy. It is therefore not necessary to define leaf topics in the tree if they do not have explicit ACLs.

ACLs and wildcard topics

With WebSphere Message Broker you cannot associate an explicit security policy with a wildcard topic. For example, you cannot associate an ACL with topic "A/+", which represents a two level hierarchy and includes "A/B", "A/K", and "A/P".

However, WebSphere Message Broker does guarantee correct access mediation when a client application subscribes to a wildcard topic.

For example, the topic "A/+" does not, and cannot, have a security policy explicitly associated with it. Therefore, "A/+" inherits its policy from "A". Any user can subscribe to "A/+" because the subscribe ACL includes everyone.

When a message is published on "A/P" or "A/K", the broker delivers it to the user who subscribed to "A/+". However, when a message is published to "A/B", that message is only delivered to subscribers who are in the HR group.

If the system administrator changes the subscribe ACL of any topic that matches "A/+", the broker correctly enforces the ACL when the message is delivered. Subscribing to a wildcard topic has the semantics to deliver messages on all topics that match the wild card, and for which the subscriber has authorization to receive that message.

ACLs and subscription resolution

The broker enforces access control through the topic of the message to be delivered. Messages are delivered only to those clients that have not had subscribe access to that topic denied, either explicitly or through inheritance. Because a subscription can contain a wildcard character, the actual match against the topic namespace, and hence the topic ACLs, cannot be made when the subscription is received. The decision to deliver a message to a subscriber is made only when a specific message with a topic is being processed by the message broker.

Activating topic ACL updates

Updates to a topic ACL do not become active until deployed and activated across the broker domain from the WebSphere Message Broker workbench.

You must have an object-level security ACL that gives full control permission to the root topic object.