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.
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 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.
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.
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.
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.
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".
Do not configure ACLs on topics that begin with the string "$ISYS". You are not prevented from doing so, but the ACLs are ignored.
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.
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:
|
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
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 |
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.
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.
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.