[zeromq-dev] ZeroMQ WebSocket Transport: authentication

Frank Hartmann soundart at gmx.net
Sat Aug 16 18:02:01 CEST 2014

Michael Haberler <mail17 at mah.priv.at> writes:

> while designing the ZWS frame-level protocol, authentication came up
> since the proxy will eventually connect to a zeromq socket, it is open
> to me how this will fit in with authenticated zeroMQ sockets, and what
> kind of interaction needs to be brought forward to the ZWS websocket
> to cover this scenario
> first guess - if we can map the woodhouse, stonehouse and ironhouse
> patterns to ZWS that'd be great; strawhouse doesnt apply at the
> end-to-end level but rather the proxy-to-end level and hence not part
> of the ZWS protocol
> for confidentiality I guess wss (websockets over TLS) is good enough,
> but for authentication I think hop-by-hop isnt
> any suggestions how to go forward on this?
> - Michael
> see also: https://github.com/zeromq/JSMQ/issues/3


really interesting topic! 

I cannot contribute much, but for a distributed home automation project
I was thinking of connecting zeromq speaking heating systems of houses
towards a central web-portal.

I was not aware of the work Doron and you are doing wrt to websockets so
I was thinking of building a C++ websocket <-> zeromq 'bridge' running on
the machine with the web-portal. Javascript would talk over websocket
with the bridge listening on localhost. The bridge would talk zeromq
towards the distributed heating systems.

I have found the following hints with respect to authentication


derived from this: http://lucumr.pocoo.org/2012/9/24/websockets-101/

and found this somewhat lacking and way too complex for me.

So instead of having a central web-portal for all heating systems (1:N
mapping) combined I was thinking of running a dedicated VM foreach
heating system serving that web-portal. So it will propably be more of a
1:1 mapping.

Anyway what I wanted to add: The best practice "Avoid tunneling"
seems to be violated by your approach, if I understand things correctly?
Basically it is 'raw' 'zeromq' coming from javascript, isn't it? 

On the other hand I have not fully understood why the situation would
improve or how I could implement "a checked and secured" higher-level
protocol if I cannot trust the data coming from the browser?

kind regards 

More information about the zeromq-dev mailing list