If your middleware it trusted, you can just use libzmq/CURVE between
clients and the portion of the middleware that has high security
posture, and libzmq/NULL between middleware that has low security
posture and your broker, and also NULL between the broker and the
agents. Then you don't need libcurve.
But without a diagram, I am not sure to understand your architecture.
As far as I know, libcurve does not have any bindings.
Le 20/03/2014 16:44, Dave Quigley a écrit :
Well the middleware is trusted. The idea is that one portion has a high
security posture while the other has a low security posture and the
middleware mediates messages across that boundary. I had an idea of
taking the message off the broker wrapping it in the middleware message
and sending it across the boundary and unwrapping the replies and
sending them back. However I'm not sure if I have to do some of the
stuff mentioned in the advanced rep/req section and handle the frames
instead of entire messages. There is a lot of good information in the
guide so its taking a while to internalize it all. I need to find out if
there are python bindings for the libcurve stuff.
Dave
On 3/20/2014 9:31 AM, Laurent Alebarde wrote:
If you have to go through untrusted nodes, then you need libcurve on top
of libzmq. You cannot use CURVE inside libzmq since it does not permit
proxying as is. Though I have managed to do it with the help of
ZMQ_STREAM, it is heavy and I finally prefer putting security on top of
libzmq.
As your middleware is untrusted, it should not be used to dispatch the
jobs. I would allow it only for minimal proxying. Then, I suggest you
keep your first idea of a broker/dealer server with agents in the
trusted area.
Keep in mind that using libcurve or libzmq/CURVE through proxy requires
being statefull. So your broker shall perform sticky pairing between
clients and agents. If you cannot aford being stateful, you have to
consider other security solutions.
Le 20/03/2014 14:01, Dave Quigley a écrit :
I read through the guide so I have some idea of what I need to get the
job done. Unfortunately I'm having some odd middle ware being pushed on
me so its not as straight forward as I had originally planned. I
originally have a client using a req/rep socket to a management server
which would use a broker/dealer socket pair to pass the messages along
to the local portion of the management agents. However now I'm told that
I have a hard separation between components sitting in a
trusted/privileged zone vs untrusted zone and I have to use their
middleware messaging system to communicate across that boundary. However
I still want to use zmq from the client to the trusted management
component and then from the untrusted management component to the local
servers it starts for interacting with the remote agents. I'm not sure
if I need the broker/dealer pairs for that anymore or if I make the
components on each side of the middleware just be normal servers that
are reponsible for proxying the requests through the middleware.
Unfortunately this middleware makes it go from a clear cut picture to
very murky waters.
Dave
On 3/20/2014 6:04 AM, Laurent Alebarde wrote:
My two cents:
Do architect your system roughly, then perform minimal tests of the
library features you expect to use, consider what's available in a
second choice library, then abstract what's useful for you in the
library of your choice in a layer of your own, keeping the second choice
in mind, for easier move and independence. Build your system with an
iterative process, refining your design and adding features, but the
main ones shall be in the architecture at the very beginning, or you
will have to iterate from scratch several times or end with a spaghetti
code.
It is not the opposite of Pieter's bottom-up advice, but a top-down and
bottom-up approach in an iteration process.
But none of us have answered your question. As far as I know, this list
is the only one. But as Pieter points it out, reading the Guide is a
very good mandatory start.
Laurent
Le 20/03/2014 08:45, Pieter Hintjens a écrit :
Hi Dave,
For the most part, reading the Guide and learning ZeroMQ by working
through various examples will teach you everything you need. There is
some general advice: don't architect systems, then build them. Rather,
start with minimal end-to-end proofs of concept, then work them out
incrementally.
-Pieter
On Thu, Mar 20, 2014 at 6:24 AM, Dave Quigley<dpqu...@davequigley.com> wrote:
I'm working on developing a framework for management and tasking of
remote administration agents. I've chozen zmq as my messaging library
since it is lean and gives me an abstraction that I like. Is this the
right place to ask about how I'm architecting the system or is there a
better venue? The freenode channel is pretty quiet and I've noticed this
list is mostly questions about c/c++. I'm currently using pyzmq just as
a way to quickly prototype something with the hopes of transitioning it
over to C when I figure everything out.
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
