[zeromq-dev] pubsub modelling

[Martin Sustrik]

Steven McCoy wrote:
> On 21 April 2010 11:52, Bhavin Turakhia <bhavin.t at directi.com 
> <mailto:bhavin.t at directi.com>> wrote:
> 
>     Hi
> 
>      
> 
>     I have been thinking about some basic pubsub modeling on top of
>     ZeroMQ. The one area which requires some thoughts is permissioning.
>     In a typical pubsub environment there is a list of subscribers
>     maintained for a node. Only those subscribers are permitted to
>     connect and subscribe to the node
> 
> 
>     ZeroMQ obviously does not have this capability and thus it would
>     need to be layered above. I can think of the following models for
>     the same –
> 
>      
> 
>     * Proxy: The subscriber client establishes a socket connection to
>     zero through a proxy of sorts which checks whether the subscriber
>     has the rights to connect to this node and if not returns an error
>     and does not let the connection through
> 
>      
> 
>     * Topic change: Keep changing the name of the topic in question to a
>     random guid. The subscriber must talk to an independent system first
>     to fetch the current name of this topic. The api that permits this
>     is the one that checks permissions of that subscriber. Once the
>     subscriber has the topic name then it can directly connect to the
>     queue. Incase the permissions on the node change, the topic name is
>     changed again and all current subscribers are disconnected forcing
>     them to reconnect
> 
>      
> 
>     Has anyone else thought of any other models?
> 
> 
> If it's a closed system permissions usually should be on the edge, so 
> ideally sitting on the client if you are using multicast.  On an open 
> system you will need a locked down broker gateway.
> 
> Note you might want to consider adding auditing & accounting into any 
> permissions system, whenever someone subscribes you should send a 
> messages all the way up through the model.
> 
> Some cases you may also need to proxy clients, such as a webserver with 
> multiple users connecting to an application server through 0MQ.

Right.

Imagine a data distribution tree with multiple levels of redistribution. 
Imagine the middle nodes are not trusted.

The only way to deliver content only to entitled consumers AFAICS is to 
encrypt it on the sender and decrypt it on terminal receivers.

Martin