Подход MassTransit, когда затрагиваются темы Azure Service Bus и безопасность

Question

Я реализую библиотеку для издателей и потребителей событий, чтобы общаться через Azure Service Bus, и я думаю, что MassTransit может быть хорошим вариантом.

Я могу работать, публикуя sh несколько событий с и несколько потребителей получат их без каких-либо проблем, если я позволю MassTransit создавать те темы, которые ему нужны, и указав для потребителя только конечную точку получателя для 3 типов событий, в которых я указываю имя очереди.

Пример потребителя :

var busControl =
    Bus.Factory.CreateUsingAzureServiceBus(
        cfg =>
        {
            CreateAzureServiceBusHost(cfg, serviceBusUri, serviceBusKeyName, serviceBusKey);

            cfg.ReceiveEndpoint(queueName, endpoint =>
            {
                foreach (var eventDtoType in eventsTypes)
                {
                    var adapterType = typeof(EventHandlerAdapter<>).MakeGenericType(eventDtoType);
                    var resolvedType = sp.GetService(adapterType);
                    endpoint.Consumer(adapterType, type => resolvedType);
                }
            });
        });

Обратите внимание, что я указываю в качестве потребителя EventHandlerAdapterType<TEvent>, потому что у меня есть адаптер для абстрагирования обработчиков событий от MassTransit. Но это не имеет значения для этого вопроса.

Издатель настроен следующим образом:

var busControl =
    Bus.Factory.CreateUsingAzureServiceBus(
        cfg =>
        {
            CreateAzureServiceBusHost(cfg, serviceBusUri, serviceBusKeyName, serviceBusKey);
        });

Проблема заключается в том, что мне нужно использовать эту библиотеку, интегрированную с системой, которая создает ее собственные темы, и в нем есть защита ( только некоторые приложения могут публиковать sh, только определенные приложения могут читать сообщения, опубликованные в этой топи c)

Мне нужно создать токен sas для издателя, который хочет опубликовать sh события по определенным темам, и для потребителей, которые хотят читать из определенных тем . Однако создание токена выходит за рамки этого вопроса.

МОЕ РЕШЕНИЕ РЕШЕНИЯ : Я готовлю следующий сценарий в Azure Шина обслуживания: - Создать топи c topic-attempt-one (включенный раздел, хотя не уверен, если это уместно) - Создайте подписку subscription-attempt-one внутри этого topic-attempt-one - Создайте политику общего доступа в topi c SamplePublishOnly с разрешениями только для отправки - Создайте политику общего доступа в topi c SampleReadOnly с правами только для прослушивания

Я изменяю свой пример, чтобы издатель использовал ключ и keyName согласно SamplePublishOnly, а два потребителя использовали ключ и keyName согласно SampleReadOnly

На издателе я настраиваю его на использование одинаковых топиков c для 3 различных событий.

var busControl =
    Bus.Factory.CreateUsingAzureServiceBus(
        cfg =>
        {
            CreateAzureServiceBusHost(cfg, serviceBusUri, serviceBusKeyName, serviceBusKey);
            // Here I add the same topic name for the 3 event types I want to publish.
            cfg.Message<IEventOne>(topology =>
            {
                topology.SetEntityName("topic-attempt-one");
            });
            cfg.Message<IEventTwo>(topology =>
            {
                topology.SetEntityName("topic-attempt-one");
            });
            cfg.Message<IEventThree>(topology =>
            {
                topology.SetEntityName("topic-attempt-one");
            });
        });

Потребитель, который я настраиваю с конечной точкой получения ( с одним именем очереди для одного потребителя и другим для потребителя два) для трех сообщений с добавлением указания именно topi c и используемой подписки.

var busControl =
    Bus.Factory.CreateUsingAzureServiceBus(
        cfg =>
        {
            CreateAzureServiceBusHost(cfg, serviceBusUri, serviceBusKeyName, serviceBusKey);

            cfg.ReceiveEndpoint(queueName, endpoint =>
            {
                //I specify the topic and subscription name that is already created in ServiceBus
                endpoint.Subscribe("topic-attempt-one", "subscription-attempt-one");
                foreach (var eventDtoType in eventsTypes)
                {
                    var adapterType = typeof(EventHandlerAdapter<>).MakeGenericType(eventDtoType);
                    var resolvedType = sp.GetService(adapterType);
                    endpoint.Consumer(adapterType, type => resolvedType);
                }
            });
        });

var busControlWrapper = new BusControlWrapper(busControl);
return busControlWrapper;

Минусы Умерс не может сейчас запустить автобус. Думаю, есть проблема с правами доступа:

Microsoft.Azure.ServiceBus.UnauthorizedException: Manage,EntityRead claims required for this operation. TrackingId:2d6953d0-c8e1-4bdc-bed5-cc6e5d2d1f9e_G27, SystemTcker:sunnyatticsoftware.servicebus.windows.net:topic-attempt-one, Timestamp:2020-03-07T20:26:38

Хорошо, поэтому я решил создать две очереди вручную в Azure Service Bus для каждого потребителя, надеясь, что MassTransit может создавать виртуальные очереди, если это необходимо для разных сообщений. - Создайте queue-one - Создайте политику общего доступа с утверждениями только для Listen, и я называю ее QueueReadOnly и пытаюсь использовать ее keyName и key.

Ничего. Другая ошибка, но все еще не может заставить ее работать

 Microsoft.Azure.ServiceBus.UnauthorizedException: claim is empty. TrackingId:9e344a3f-d40a-475d-bf61-7aae274ed2d1_G17, SystemTracker:sunnyatticsoftware.servicebus.windows.net:topic-attempt-one, Timestamp:2020-03-07T20:40:33

, что имеет смысл, потому что я говорю ей использовать специфицированный c topi c и подписку, но не использовать токен с чтением разрешения на них, поскольку я заменил его на очередь.

ВОПРОСЫ

• это правильный подход для моего сценария?
• это нормально, чтобы попытаться поделиться одной и той же topi c для публикации 3 различных типов сообщений? Кажется, дизайн MassTransit заставляет меня использовать один topi c на сообщение.
• как достичь того, что мне нужно? Как другие справляются с разрешениями, если я не хочу, чтобы издатель MassTransit и потребители использовали маркер полного разрешения Manage, потому что я не хочу, чтобы потребители, например, публиковали sh на топике c?

Спасибо!

PS: Я обнаружил похожую проблему, но, к сожалению, она не решает мою проблему. Как указать Azure Topi служебной шины c для использования с MassTransit

Обновление 1

Я нашел это: Возможно ли использовать MassTransit 3 с Azure Service Bus без политики разрешений Manage?

, что, если это все еще относится к последней версии 6.2, может объяснить, почему я получаю эти ошибки. Жаль, если я не могу использовать какие-либо претензии, кроме «Управление». Итак, нет гранулярных разрешений с Masstransit? Как можно запретить приложению, имеющему токен Manage, читать сообщения, которые он не должен читать? Если создание объектов, таких как темы, подписки или очереди, не вариант, возможно ли использовать Masstransit?

Я предполагаю, что мне не хватает знаний, поэтому любая ссылка также будет оценена!