Isolated topic namespace for MQTT - mqtt

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.

Related

Restricting / Protecting Topics with MQTT and Solace

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.

Partitioning a Mosquitto MQTT Server

I want to create isolated environments on a single MQTT server. Like a database server can have multiple schemas and table names can be repeated in different sachems. I want to have a "MQTT schema" where topics/subscriptions in one schema are isolated from those in another "MQTT schema" so that the same topic can be used in different schemas. It would be even better if security can be applied on a per schema basis but that would be asking for a lot. Right now, I am just looking for a way to have isolated environments on the same server - it will probably require a separate TCP port per schema just to identify the destination schema of a connecting client, as the protocol itself does not have have any concept of schema. Or the clients can be mapped to a particular schema based on the username or client ID.
Note: I am aware of how to use ACL to restrict topic access for each user. ACLs do not solve this problem. I don't simply want to restrict topic access, I want to create separate environment where users are free to do what the want with the topics without out me telling them which topic names they cannot use etc.
The other option is the mount_point configuration option that can be used with a listener declaration (man page).
mount_point topic prefix
This option is used with the listener option to isolate groups of clients. When a client connects to a listener which uses this option,
the string argument is attached to the start of all topics for this
client. This prefix is removed when any messages are sent to the
client. This means a client connected to a listener with mount point
example can only see messages that are published in the topic
hierarchy example and above.
The difference between this and the other option (docker container) is that you can have listener declarations that can see all the traffic of all the different partitions by having a listener with no mount point.
Just use a docker container running mosquitto and spin up new instances for each schema. Map each instance to a separate external port. Total isolation and of you include the auth plugin you can map the security to a separate db table for each schema with environment variables

MQTT, is it possible to block publications for everyone besides localhost, and leave the subscriptions open to everybody?

What I want to do is to have data published from localhost only.
But I need to allow any user in the web to subscribe to that topic, is it possible to do with MQTT? How?
If not, do I have any other options to fullfill this specifics.
Additional information:
Using MQTT protocol to post.
Using Websockets to subscribe.
Using Mosquitto as broker.
Most MQTT brokers support ACLs to limit access to topics to specific users. They also tend to allow a ACL for unauthenticated (annonymous) users.
So you should be able to define a specific user that you can use to publish from localhost and then set up an anonymous ACL that only allows subscriptions to #
For Mosquitto the acl file would look something like:
user publisher
pattern readwrite #
user anonymous
pattern read #

MQTT subscribe to # topic allows the user to read all messages?

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.

Managing MQTT topics in WSO2 MB management console

in WSO2 MB management console I'm trying to restrict read and write access for topics to certain users and roles, but it seems that it only effects JMS but not MQTT messaging, despite WSO2 MB states to support this protocol.
I would like to restrict subscribing and publishing to single roles, so a user can either publish or subscribe to a topic but not both.
Are there any solutions?
Oliver
Even though mqtt spec didn't specifically define authorization model. Workaround has been implemented recently as an experimental feature for MB 3.2.0 alpha. Implementation is based on carbon permission model with a known limitation of permissions can be defined only for static topics. Please note that this will not be visible in wso2 message broker ui permission tree. Please go through draft documentation in public Jira for more information.

Resources