1

I have the following architecture: 1 topic where a publisher publishes messages and 3 subscriptions. All messages are dispatched in the 3 subscriptions thanks to a "1=1" rule. The 3 subscriptions are created to provide the message published to 3 different apps. I have a SAS key for the publisher with the "Write" permission on the topic. I now need to create 3 SAS keys with "listen" permission for the 3 apps but I saw that I can't associate a key with a subscription, only with a topic or at the namespace level. What I'm looking for is a way to avoid the app #1 to listen to the subscription that is not dedicated to it. Is it possible to do that?

David GROSPELIER
  • 772
  • 1
  • 9
  • 35
  • 1
    The SAS keys are created at topic level. You just create a single Listen key for the topic and use that for all three subscriptions. I don't think it's possible to prevent an application from listening via the "wrong" subscription as long as it has the topic listen key. Are you in charge of the listener applications? – spodger Nov 07 '17 at 08:35
  • No I'm not in charge of the listener applications, I'm providing the subscription and the key to this app and this will be managed by another team. This is why I want to prevent this app to listen to another subscription of the topic because other subscriptions are dedicated for other apps. – David GROSPELIER Nov 08 '17 at 08:50

2 Answers2

0

The only way that I'm aware of to achieve that would be by having three separate "listener" topics with Listen and Send SAS keys.

In order to decouple this from your publisher application you could keep the "publish" topic with it's Send SAS key and create a Listen subscription and SAS key and write a small second "broadcaster" application which simply reads the "publish" topic and distributes the messages to the three "listener" topics.

That way only you would know the all 4 Send SAS keys and the Listen SAS key for the primary "publish" topic and you can distribute the three other Listen SAS keys independently.

I'm sure you probably considered this but felt there must be an easier way! :-)

I had a quick look at Event Hubs and Relays but Relays seemed inappropriate and Event Hubs may provide the functionality but it's not really what they're intended for, I believe. I think they also cost a lot.

spodger
  • 1,668
  • 1
  • 12
  • 16
0

You could create an additional queue for each subscription, enable auto-forwarding from each subscription to its associated queue and configure a listener policy on each of the queues, so each client can read only from its dedicated queue.

The obvious downside is it does mean configuring the 3 additional queues and the auto-forwarding. But it should provide full isolation between receivers.

andyb
  • 1