On 21 April 2010 11:52, Bhavin Turakhia <[email protected]> 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. -- Steve-o
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
