[zeromq-dev] Authenticated pubsub (was Access control)

Burak Arslan burak.arslan at arskom.com.tr
Tue Jul 27 23:10:05 CEST 2010


there seem to be many problems with below scheme, most serious being its
ambiguity. e.g. what are "authentication credentials"? are you sending
username/password as cleartext?

also, what concern are you trying to address? integrity?
confidentiality? (i'm not sure what a game would need) are you doing any
sort of logging somewhere? if so, do you log messages as cleartext? if
not, will they be decipherable 10 years from now? where would you store
the keys?


i see two ways to add security to pub/sub model:

1) let anybody subscribe to any stream, but distribute decryption keys
to only authenticated people (using 0mq or not). many key distribution
schemes that address various needs exist. this will work without any
change to the zeromq protocol. (same has here:
http://lists.zeromq.org/pipermail/zeromq-dev/2010-July/004670.html just
don't invent your own key distribution scheme)

2) if you're not comfortable publishing the ciphertext, or have other
concerns like resource usage, the 0mq protocol must be extended to
support (preferably pluggable) authentication / authorization mechanism.
authentication for "who gets the messages" and authorization for "this
guy gets which messages". the task of   designing a protocol that'll
satisfy everyone's needs is daunting at best :)


On 07/27/10 20:28, Pieter Hintjens wrote:
> Here is, I think, how to build an authenticated pubsub service using
> 0MQ.  The design handles authentication, arbitrary routing criteria,
> and flushing of dead client connections.
> You will use ZMQ_XREQ at the client side and ZMQ_XREP at the service
> side.  There is a simple protocol between client and server that is
> loosely modelled on HTTP:
> * Client sends messages containing: identity (0MQ adds this
> automatically), authentication credentials, and subscription criteria.
> * Server sends messages containing: identity (automatic),
> error/success code, and content.
> The server has two main data structures:
> * A connection table that stores authenticated identities and
> timestamps.  Each identity corresponds to a client connection.
> * A routing table that maps message keys (e.g. topic value) to
> identities.  There are techniques for doing
> [http://www.zeromq.org/whitepapers:message-matching high speed message
> matching].
> The client has a single thread that polls on its ZMQ_XREQ socket.  At
> regular time intervals it (re)sends its authentication and
> subscription message.  This acts as a keep-alive.
> The server has a two threads, one that polls on its ZMQ_XREP socket
> and one that receives outgoing messages and passes them to the polling
> thread via inproc sockets.  The polling thread processes any incoming
> client requests and updates its data structures.  It processes any
> outgoing messages by looking up the message key in its routing table
> and then sending the message (one to one) to all matching identities.
> As it does this it deletes any expired identities.
> That's it.  Sorry if I got some things wrong here, it's theory and not
> based on running code.
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list