MQTT topic subscription permissions / disable wildcards?

[nick]

Hi,

is it possible with rabbitmq mqtt to grant per user subscription&publisher access to a specific MQTT topic? (in order to avoid curious people and spamers)
is it possible to enable / disable to all users the subscription to wildcards?
is it possible to enable / disable to certain users the subscription to wildcards?

Thank you for your help!

[Michael Klishin]

No. MQTT the protocol does not have any kind of authorisation.

You can limit access to certain queues using regular access control means [1]
but that wouldn't result in sensible error messages for clients (again, MQTT the protocol
doesn't have a way for server to indicate an authorisation failure to clients). 

1. http://www.rabbitmq.com/access-control.html
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[nick]

No problem for the error messages, I am just interested in the permission control itself.

Will rabbitmq support individual permissions of 100 000 users to a few different MQTT topics each time?

I thought subscription queues where created on the fly and are individual to each clients - how can the queue control help in this case? Will it prevent the creation of such subscription queues on the fly?

Thanks

1. http://www.rabbitmq.com/access-control.html - tracked

[Michael Klishin]

On 24 December 2014 at 13:51:42, nick (nico.sw...@gmail.com) wrote:
> Will rabbitmq support individual permissions of 100 000 users
> to a few different MQTT topics each time?

There are no topics in RabbitMQ's main protocol. You can limit access to certain operations on exchanges and queues that are used under the hood to imitate MQTT's model (which is not radically different, of course,
but certainly not identical).

> I thought subscription queues where created on the fly and are
> individual to each clients - how can the queue control help in
> this case? Will it prevent the creation of such subscription
> queues on the fly?

It depends on what you allow or disallow. See http://www.rabbitmq.com/access-control.html.

MQTT plugin uses queue.declare, queue.bind, basic.publish and basic.consume. You can see queue
names and their bindings in the management UI. I suspect that limiting queue.bind and basic.consume
maybe be close enough.

[nick]

Hi Michael,

I wanted to follow up on the topic permissions for the MQTT.

In your opinion, is it possible for an experienced erlang developer to add a permission mechanism in the MQTT plugin to allow subscription to some topics, backed by a nosql database in order to update the permissions without having to restart rabbitmq?
Is the plugin launched and run permanently in a thread, at startup by rabbitmq? (so that it would not have to reestalish dabatase connectivity each time)?

Thank you for your help!

Le mercredi 24 décembre 2014 11:10:11 UTC, Michael Klishin a écrit :

On 24 December 2014 at 13:51:42, nick (nico.sw...@gmail.com) wrote:
> Will rabbitmq support individual permissions of 100 000 users  
> to a few different MQTT topics each time?

There are no topics in RabbitMQ's main protocol. You can limit access to certain operations on exchanges and queues that are used under the hood to imitate MQTT's model (which is not radically different, of course,
but certainly not identical).

> I thought subscription queues where created on the fly and are  
> individual to each clients - how can the queue control help in  
> this case? Will it prevent the creation of such subscription  
> queues on the fly?

It depends on what you allow or disallow. See http://www.rabbitmq.com/access-control.html - tracked.

[Michael Klishin]

On 6 January 2015 at 23:43:38, nick (nico.sw...@gmail.com) wrote:
> I wanted to follow up on the topic permissions for the MQTT.
>
> In your opinion, is it possible for an experienced erlang developer
> to add a permission mechanism in the MQTT plugin to allow subscription
> to some topics, backed by a nosql database in order to update the
> permissions without having to restart rabbitmq?
> Is the plugin launched and run permanently in a thread, at startup
> by rabbitmq? (so that it would not have to reestalish dabatase
> connectivity each time)?
>
> Thank you for your help!

Sure. The plugin is a really small codebase. You can implement a decent
in-memory caching of hot permissions data with Erlang, too.

[nick]

"You can implement a decent in-memory caching of hot permissions data with Erlang, too"

You mean without requiring an external database? What would happen in case of shutdown of rabbitmq then?

Could you recommend me a good contractor for such a project? (hot permissioning for this plugin with an external db)?

Thanks Michael

[Michael Klishin]

On 7 January 2015 at 00:18:30, nick (nico.sw...@gmail.com) wrote:
> "You can implement a decent in-memory caching of hot permissions
> data with Erlang, too"
> You mean without requiring an external database? What would
> happen in case of shutdown of rabbitmq then?

Not to replace, just not to pay the database query penalty for every published message.

> Could you recommend me a good contractor for such a project? (hot
> permissioning for this plugin with an external db)?

I personally can't. You can post a position to this list (this is perfectly fine) and contact in...@rabbitmq.com,
Pivotal has a professional services arm and a short list of trusted companies to recommend for Erlang
projects.

[nick]

Thanks Michael!

What cost/number of days would you roughly estimate for such a project?

[Michael Klishin]

On 7 January 2015 at 00:36:46, nick (nico.sw...@gmail.com) wrote:
> What cost/number of days would you roughly estimate for such
> a project?

Depends on what data store you want to use, some have good Erlang clients and some don't.
If there's a good enough data store client available, I believe it should take an experienced Erlang developer
5-10 days. 

[nick]

What persistent datastore would you recommend, assuming "only" 10-50k users, hence probably 100k permission entries (hence no need for a big no sql architecture, but still need clustering for failover)

[Michael Klishin]

On 7 January 2015 at 00:59:31, nick (nico.sw...@gmail.com) wrote:
> What persistent datastore would you recommend, assuming "only"
> 10-50k users, hence probably 100k permission entries (hence
> no need for a big no sql architecture, but still need clustering
> for failover)

Anything is going to work fine. I'd recommend PostgreSQL or Cassandra, depending on how
important availability is for your case. [1] seems to be a decent client for Cassandra 2.0+ (native protocol).

1. https://github.com/matehat/cqerl 

[Laing, Michael]

Actually, the spec requires an indication of success or failure for each subscription:

The SUBACK Packet sent by the Server to the Client MUST contain a return code for each Topic Filter/QoS pair. This return code MUST either show the maximum QoS that was granted for that Subscription or indicate that the subscription failed [MQTT-3.8.4-5].

...

Allowed return codes:
0x00 - Success - Maximum QoS 0 
0x01 - Success - Maximum QoS 1 
0x02 - Success - Maximum QoS 2 
0x80 - Failure 

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send an email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Klishin]

+rabbitmq-users

 On 30 January 2015 at 14:37:24, nico swiperlab (nico.sw...@gmail.com) wrote:
> I have a follow up question regarding the MQTT plugin.
>
> I noticed there is a unacked_pubs tree to track of unacked MQTT.
> Is it realistic for a developer to add a '1 second timeout' on thisunacked_pubs,
> so that it fires a message to an AMQP queue in case of unacked message
> by client? (without messing with the performance/real time)

You can use a timer that checks the size of unacked_pubs and publishes a message
as needed, then re-registers itself.