Hi Charlie, Indeed the support for user IDs appeared in 4.1. Typically the authenticator uses the client public key to read a certificate and extract the user id from that.
As a workaround you can simply send metadata yourself and maintain state per client connection. You do then have to trust authenticated clients to behave. -Pieter On Mon, Aug 17, 2015 at 5:21 PM, Charles West <[email protected]> wrote: > 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 > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
