[zeromq-dev] How do I find out which ZAP user I'm talking to? (zap rely field 5)

Drew Crawford drew at sealedabstract.com
Tue Dec 31 07:50:33 CET 2013


Hey folks,

I’ve got a REQ-ROUTER architecture where clients (with a REP socket) connect to a server (with a ROUTER socket).  This connection is authenticated via CURVE.

I need to figure out some person/username/unique identifier that is associated with the incoming REQ.  There are a couple of reasons.  One is that not all users have the same level of access privileges.  For example, there’s an admin user, with more powers than the other users, and so I need to allow some types of REQs only for that user.  Another reason is that in this application, users live inside their own sandbox more or less.  So a REQ that lists data, should only be listing data that the current user is allowed to see.

rfc.zeromq.org/spec:27/ZAP is apparently built to solve this problem, and the reply even has a field (field 5, "The user id, which SHALL contain a string.”) which looks like it is built for the purpose of associating a username with a session.  Presumably I would just fill that field with the username (e.g. “billgates”) when I am satisfied that the user has authenticated successfully as Bill Gates.

The problem is that at the time that a request comes inbound on my ROUTER, the only data I (seem to) have about the sender is some opaque (to me) identity bytes in the message envelope.  And I do not see a way to take those opaque bytes and convert them into either billgates, the client’s public key, or any other identifying information that would let me figure out who is making the request.

In an attempt to see where field 5 goes, I have traced the parsing of the zap field into curve_server.cpp (https://github.com/zeromq/libzmq/blob/master/src/curve_server.cpp#L617) and as far as I can tell it’s unused.  So it’s possible that the feature I’m looking for isn’t implemented.

Any suggestions for how I can identify the sender of a REQ, either within the current 4.0.3 release, or a general sketch of a patch I could write that would solve this problem?

Drew


More information about the zeromq-dev mailing list