[zeromq-dev] Access control

Oliver Smith oliver at kfs.org
Mon Jul 26 15:37:27 CEST 2010


I'm in the throws of converting one of our data transports to ZeroMQ. It 
occurred to me that I could let our end-user clients connect to this to 
tap into the stream directly rather than the manual re-forwarding that 
we do now.

But we don't want them randomly creating their own clients that connect 
to it. (Our product is an online game, http://www.battlegroundeurope.com/)

A little bit of searching seems to indicate ZMQ doesn't have anything 
like this ... yet.

Because ZMQ abstracts the connections, it seems a little more involved 
than the ordinary connection authentication, but I can see solutions to 
almost all cases except PUB/SUB (which, dangit, is the one I want to use 
at the moment ;-P)

Off-the-cuff what I imagine is an extension of regular pub/sub, where 
the pub-end doesn't add incoming connections to the multicast list until 
they have auth'd:

ps = ctx.socket(ZMQ_AUTHPUB)
ps.setsockopt(ZMQ_AUTHAGENT, "inproc://authentication-threads")

When this socket is connected, ZMQ quietly opens a ZMQ_REQ socket to 
"inproc://authentication-threads".

[ s.authSocket = s.context.socket(ZMQ_REQ) ]

The client would then do:

cs = ctx.socket(ZMQ_AUTHSUB)
cs.setsockopt(ZMQ_AUTHTOKENS, "user=fred,pass=password", strlen(that))

The auth-tokens are opaque to zmq, it's just going to forward them.

When this client connects to the PUB, ZMQ automatically sends the auth 
token.

On receiving an auth token, the pub listener forwards the received 
auth-tokens along with, perhaps, the originating IP address in 
dotted-decimal notation, to the authenticator...

ps.authSocket.send(printf("%s:%s", inet_ntoa(sourceIP), incomingTokens))

The authenticator - which is a user supplied piece of code - checks if 
this connection is permitted to go onto the actual multi-cast list and 
sends back approval.






More information about the zeromq-dev mailing list