Hey Arnaud, Thanks.
That makes sense, but the zmq_msg_gets function isn't available in ZMQ 4.0.4 (I wish it was!). Laszlo has ported 4.1 to Debian as the libzmq5-dev package and I just submitted a request to Ubuntu to have the package ported. Till then, I guess the choice is not doing per connection things until the package is out or including the ZMQ 4.1 version as part of the project to be compiled/linked to. Thanks again, Charlie West On Mon, Aug 17, 2015 at 10:48 AM, Arnaud Kapp <[email protected]> wrote: > Hello, > > There is an easy way to do what you want, but it isn't obvious at > first. ZAP is actually allowed to set a "User-Id" meta-data property > for all messages from a connection. > This means that your ZAP code can chose to set the curve key as the > user-id for the connection. > > To set a user-id property from the ZAP handling code, you simply have > to specify it in the ZAP reply you write. You will then be able to > retrieve the user-id (which would be the curve public key, if you > chose so) by doing something like zmq_msg_gets(msg, "User-Id"); > > Hope this helps. > > On Mon, Aug 17, 2015 at 4:03 PM, Charles West <[email protected]> wrote: > > Hey Pieter, > > > > Thank you for taking the time to respond. > > > > I have read both of the blog entries, the source for zauth and based my > code > > off of the specification for the ZAP protocol. The closest/most relevant > > documentation I saw was your discussion with Stephen Eley in the "Confirm > > authentication and retrieve metadata?" thread. > > > > If I may ask, is there some obvious way that I am missing to get the key > > associated with a connection with a Router in ZMQ 4.0.4 (the zmq > available > > in the Ubuntu repositories)? Alternatively, is there any good way to > figure > > out which router connection a ZAP request refers to? > > > > > > I apologize if I have missed something obvious, but the examples I have > seen > > seem focused on go/no go authentication rather than keys with different > > levels of permissions. > > > > Thanks, > > Charlie West > > > > > > On Mon, Aug 17, 2015 at 6:35 AM, Pieter Hintjens <[email protected]> wrote: > >> > >> Have you studied the security examples I wrote? > >> > >> - read http://hintjens.com/blog:48 and http://hintjens.com/blog:49 > >> - don't use ROUTER identity, the field is really a routing key and has > >> nothing to do with peer identity > >> - look at how CZMQ's zauth works, and look at the RFC for the ZAP > >> protocol (http://rfc.zeromq.org/spec:27) > >> > >> On Mon, Aug 17, 2015 at 5:43 AM, Charles West <[email protected]> wrote: > >> > Hello! > >> > > >> > I'm building the second version of a open source differential GPS > >> > sharing > >> > software (pylongps.com). I've run into a bit of a snag though. > >> > > >> > Does anyone know of a good way to get the key associated with a CURVE > >> > router > >> > connection? ZAP authentication can check if a key is on the > whitelist, > >> > but > >> > it doesn't appear to provide more than a go/no go. I need to be able > to > >> > check the key associated with a specific ROUTER connection so that I > can > >> > limit what the owner of a particular connection key can do (people > with > >> > one > >> > key can't pretend to be someone else). > >> > > >> > My original idea was to use the ZMQ_IDENTITY field to set the > connection > >> > ID > >> > to a superset of the connection key, then just have the ZAP handler > >> > verify > >> > the connection ID contained the key at the beginning. Further ID > >> > processing > >> > would then be done via the connection ID at the router socket. > However, > >> > the > >> > ZMQ_IDENTITY set does not show up in the ZAP messages, so this isn't > >> > possible. Further reading of the mailing list indicates that the > >> > ZMQ_IDENTITY isn't suppose to propagate like that anyway. > >> > > >> > The brute force solution would be to force a authentication exchange > >> > using a > >> > signing key and a nonce at the router (router sends nonce, client > signs > >> > or > >> > encrypts it and sends it back). Thats basically doing a whole > handshake > >> > on > >> > top of the ZMQ_CURVE protocol, which seems rather overkill. > >> > > >> > Does anyone know of a better approach? > >> > > >> > Thanks, > >> > Charlie West > >> > > >> > _______________________________________________ > >> > zeromq-dev mailing list > >> > [email protected] > >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > -- > Kapp Arnaud - Xaqq > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
