Missing second ACL rule

Topics should be created with two Access control list (ACL) rules if they want to use an identity topic filter. One is used for publishing and the second one for subscription. This way only authorized identity users (%u) can publish to the specific topic. For more information, see Identity topic filters guidelines.

Otherwise, the user gets the following warning:

There are one or more topics without a second ACL rule. Unintended groups may have access to the topic. For each topic represented by an identity topic filter, we recommend defining a second ACL rule where + replaces the client or user identifier in the topic filter. For example, a/b/+.

The warning applies when the first ACL rule both:

• has a topic filter in the specific configuration as an identity topic filter. It contains %u - username or %c - client ID, such as: /presence/%u/test/a/b or /%c. Refer to Topic filters.
• does not have a counterpart ACL for the second operation. The second operation is publishing when the identity topic ACL rule is configured for subscribing only, and subscribing when the identity topic ACL rule is configured for publishing.

Example of correct configuration

To make the settings useful and successful, and avoid triggering the described warning message, define two ACL rules as follows:

The first ACL rule:
Topic filter /identity/topic/%c/store
Publisher authorization groups (Pubs): pub1
Subscriber authorization groups (Subs): [] (no subs)

The second counterpart ACL rule need to be the dynamic topic filter rule:
Topic filter: /identity/topic/+/store (when the client ID or the username pattern - %c or %u - should be replaced by +)
Publisher authorization groups (Pubs): [] (no pubs)
Subscriber authorization groups (Subs): sub1

Example of incorrect configuration

These are two examples of the wrong ACL rules definitions that trigger the warning message:

Example 1

Topic filter: /liberty/%c/data
Publisher authorization groups (Pubs): pub1
Subscriber authorization groups (Subs): sub1
Client ID: client1
The pub1 authorization groups (auth groups) can publish to /liberty/client1/data.
Only the same client ID and with the sub1 auth groups can subscribe to this topic.
No counterpart ACL is configured with the /liberty/+/data topic filter for subscribing or publishing.

Example 2

Topic filter: /store/%u
Publisher authorization groups (Pubs): *
Subscriber authorization groups (Subs): *
Client ID: user1
Any auth groups can publish to /store/user1 and only the same user ID can subscribe to this topic.
No counterpart ACL is configured with the /store/+ topic filter for subscribing or publishing.

These examples demonstrate the incorrect use of the identity topic and adds pubs and subs to the ACL rule’s identity topic filter. This message only appears to clients with the same client ID or username when they publish a message while configuring the filter.

Subscribing is only possible for topics containing the client ID or the username in the path. If the ACL rule has both pubs and subs configured, it suggests that the dynamic topic filter should be used instead. It doesn’t force using only the client ID or the username parametrized topics and allows to use any topic name (using + instead %c or %u in the topic filter path) for publishing and subscribing.

You can use the identity topic’s ACL rules as a way of authorization because the subscribers need to know the client ID or the username of the publisher. However, to allow any clients, not only the publisher, to subscribe, you need to create another accompanying ACL rule with the dynamic topic filter related to the identity topic filter with only subs defined. Also when you configure the identity topic ACL rule for subscribing, you need an accompanying ACL rule with the dynamic topic filter only for publishing, with only pubs defined in this rule. See Identity topic filters guidelines.

Overlapping authorization groups

The warning message for overlapping authorization groups is related to the identity ACL rule with its counterpart being the dynamic rule case. The message reads:

One or more topics with overlapping authorization groups. Unintended groups may have access to the topic. For each topic represented by an identity topic filter and a + topic filter, we recommend defining two ACL rules where groups of publishers and subscribers are specified separately.

This occurs when both publishing and subscribing rules have:

• Subscriber authorization groups (subs) configured with empty publisher authorization groups (pubs).
• Pubs configured with empty subs.
• Both pubs and subs are configured.
• One has both subs and pubs and the other has either pubs or subs configured.

Example of correct configuration

To make the settings useful and successful, define the ACL rules as follows:

Example 1

Identity ACL rule
Topic filter: /not_overlapped_publishers/%c/identity
Publisher authorization groups (Pubs): pub1
Subscriber authorization groups (Subs): [] (empty list)

Accompanying counterpart dynamic ACL rule: /not_overlapped_publishers/+/identity
Publisher authorization groups (Pubs): [] (empty list)
Subscriber authorization groups (Subs): sub1

Example 2

Identity ACL rule
Topic filter: /subs_not_overl/%u/identity
Publisher authorization groups (Pubs): [] (empty list)
Subscriber authorization groups (Subs): sub1, sub2

Accompanying counterpart dynamic ACL rule: /subs_not_overl/+/identity
Publisher authorization groups (Pubs): sub1, sub2
Subscriber authorization groups (Subs): [] (empty list)

The Publish-Subscribe Service application view

Example of incorrect configuration

Overlapping authorization groups happens when both the identity topic filter rule and the accompanying counterpart dynamic topic rule have the same authorization groups type, and that’s why such a scenario is not recommended. That also means they both have subs or pubs at the same time.

For the ACL rule with the identity topic filter /topic/%c/store, you can publish or subscribe to the strict list of topics dependent on a list of the authorized clients (depending on whether it is configured only for a single operation both publishing and subscribing for identity topic end with the error message) e.g., when the client ids are: clientId1, clientId2, clientId3 (which have valid jwt and auth groups), the topics to publish are /topic/clientId1/store, /topic/clientId2/store, /topic/clientId3/store.

If you add the second counterpart ACL rule with the dynamic topic filter /topic/+/store with the same authorization group type as the ACL rule with identity topic: /topic/%c/store, it’s allowed to publish or subscribe not only to the listed topics such as /topic/clientId1/store, /topic/clientId2/store, /topic/clientId3/store but to any other such as /topic/it_is_not_client_id/store. The values of pubs and subs can differ.

In the other words the /topic/+/store topic filter rule extends the /topic/%c/store topic filter rule that is strictly narrowed only to the client ID related topics, because + can be replaced by anything, so it is not a desirable approach.

Examples of not recommended ACL pairs:

• Identity ACL rule: /a/%u, pubs: pub1, subs: [] (empty list)

• Dynamic ACL rule: /a/+, pubs: pub2, subs: [] (empty list)

• Identity ACL rule: /a/%u, subs: sub1, pubs: [] (empty list)

• Dynamic ACL rule: /a/+, subs: sub2, pubs: [] (empty list)

• Identity ACL rule: /a/%u, subs: sub2, pubs: pub2

• Dynamic ACL rule: /a/+, subs: sub1, pubs: [] (empty list)