I have a EMS client who currently publishes directly to a queue (A.B.C).
They are now migrating to Solace.
I can define a queue for the client on the solace broker named A.B.C, but what should I put in the ACL Profile on the publish tab? Should I used the internal queue name #P2P/QUE/A.B.C or should I defined it as A.B.C?
To control direct publishing to queues, you can use the topic pattern #P2P/QUE/A.B.C in your ACL profile.
Related
Considering MQTT's pub/sub behavior, topic namespace is not isolated and any user can access every other user's data on a topic.
I've seen services like flespi which claim they provide isolated name spaces but some of them use containers to isolate users...
Is it possible to modify an MQTT broker, e.g. Mosquitto, for that purpose? Or is there such open source broker?
Mosquitto can set access control to topics based on authentication username. This allows the administrator to restrict access to topics and restrict which clients can subscribe, publish or receive messages on particular topics. This is documented in Mosquitto’s documentation.
For greater flexibility you can also use the dynamic security plugin, or the mosquitto-go-auth plugin which allows you to use a variety of different data sources for authorization and ACL configuration.
I'm working toward an event-driven simulation infrastructure using Solace's PubSub+ for MQTT as a broker. I have a type of control message topic prefixed by control/.
Is there anyway to protect/restrict publish access to this topic prefix (or specific topics in general) to one authenticated user (i.e. the controller node)?
Thank you for your time!
yes indeed there is! What you are inquiring about is configuring access control list under the Client Authorization. Check out more information about ACLs in the docs here. ACLs are configured on the broker management console, so whether you are using a local broker (via docker for example), cloud solution (Solace Cloud) or an appliance, you access your ACLs from the "Access Control" tab and configure your users and topic subscriptions. You can also check out the Solace Community forum where you can see a bunch of people asking questions about Solace related concepts and messaging in general.
Note: if you are using MQTT to connect to the broker, you can create a username on the broker with predefined authentication. You will use this authentication during your mqtt client connection.
I am facing a problem with masstransit. I want to use SQS and one queue only. I want masstransit to always send the messages to that queue and receive them on a specific endpoint. (So not publishing).
The sending to the queue works but for some reason I'm having problems receiving messages. The documentation examples do not work for me when connecting a consumer to an endpoint.. It complains about SNS (which I am not using)
Does anyone have a simple example?
Ok, so I found out that if you want to send messages to a queue, than SQS should be sufficient in combination with Masstransit. But when you want to recieve those messages, then Masstransit expects credentials that allow the creation of SNS topics.
I thought I had more say in what queues Masstransit will use for communication. But when you use Masstransit with amazon it will create it's own queues and SNS topics based on it's needs.
So when using Masstransit, like i did in my case. Give it AWS IAM user credentials that have the proper permissions to create SQS queues and SNS topics.
I was reading this about topic subscription. So if I subscribe using a wild card, to the # topic, then I will receive all the messages.
Does that mean I could intercept the communication? When someone is publishing a message to a secret topic, then I will also get it.
Obviously that is not the case. But what am I missing?
On a related issue, how does the broker prevent users from subscribing to specific topics or publising to other? I assume not anybody can just send data to a broker. Is it somehow similar to HTTP?
With the basic out of the box configuration, anybody can connect to the broker and subscribing to # will get all the messages published and you can publish to any topic you want.
The MQTT protocol includes support for authentication as part of setting up a connection to the broker. Once you have an authenticated user it becomes possible to apply rules to what that user can do. Different brokers implement how create those rules in different ways, but mosquitto has support for ACLs.
With the ACL you can define what topics a user can subscribe and publish to. The built in mechanism for this is a flat file, but there is also support for a plugin system that allows you to keep username/password and allowed topics in a database. This allows the ACL to be easily updated without having to restart the broker.
I have a scenario where a request is sent to a service via my client now the response comes inside a message queue in azure, How can I poll the queue at client end and update the view when the response comes say I have to update a label when data is recieved in the queue.
Azure has two types of queues - Azure Queue and Service Bus Queue. Although in theory you can access them from client side (I assume JavaScript) because CORS has been introduced some time ago (Not sure about CORS support for ServiceBusQueue), this might not be the best option.
Problems you might face:
Lot's of clients trying to process messages (locking and releasing), Azure Queue does not support sessions so you would have to either create queue per client or use Service Bus Queue (as I said earlier not sure about CORS) with sessions
What should happen when your client is not online anymore? Does the message stays in the queue? Till when? Expiration?
Different approach
You can do message processing on the server and only notify user about the change using SinglalR. This gives you much better flexibility (one message can trigger notification for many users etc).
SignalR Scaleout with Azure Service Bus
Using SignalR with Azure Table Storage - What architecture?