[zeromq-dev] Fwd: Access control

[Pieter Hintjens]

On Tue, Jul 27, 2010 at 3:46 PM, Oliver Smith <oliver at kfs.org> wrote:
>
> I sort of stole my own thunder with the Why ZeroMQ thing...
>
> Anyone any ideas on this?

Perhaps I'm misunderstanding your email.  Sorry, if that's the case.

It seems a fairly common conundrum.  Since 0MQ connections are hidden
in the pattern, you can't address them explicitly.  This means
specifically:

* You don't know when they start
* You don't know when they end
* You cannot close them explicitly at the server side
* You cannot send messages to them explicitly

The first three restrictions make it impossible to use 0MQ for servers
that need to manage per-connection resources that sit above 0MQ.  You
can do a lot using REQ-XREP sockets and identities, but you still
don't have access to or control over the connection's lifecycle,
meaning your server will run out of resources if you try to use
identities for e.g. context.

For example it is impossible to extend the multithreaded server
example on the blog with a SASL-style challenge-response
authentication.

However, Martin is right that this stateless pattern is more scalable.
 It's how HTTP works.  Every request is complete in itself.  If
something is missing (e.g. authentication), the server returns an
error and the client resends the whole request.

What's missing for me is user-space routing, to implement patterns
other than those built-in to the code.  So we have topic routing.  How
about regexp routing, or XML content based routing, etc.?

Now to your problem of authenticating subscribers.  I imagine you're
not actually using multicast but TCP unicast, right?  A ZMQ_PUB socket
can connect to a ZMQ_SUB socket.  So imagine that subscribers connect
to the publisher via REQ-REP and provide their endpoint along with
authentication credentials.  The publisher verifies that and if it
matches, connects through to their endpoint.  The publisher does not
bind(), so has no endpoint for unauthorized subscribers to connect to.

If you want authentication over PGM multicast, you would need
something similar except the publisher responds with a key that
unlocks the multicast group, which must be encrypted in some way.

-Pieter