[nanomsg] Re: issue with "received" message size
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2014 09:37:51 -0700
On March 11, 2014 at 9:28:18 AM, Paul Colomiets (paul@xxxxxxxxxxxxxx) wrote:
Hi Garrett,
On Tue, Mar 11, 2014 at 5:59 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>
> I would say, that there should be option NN_ROOT_CERT, which if
> set make socket only accept client with certificates signed by that
> root. I think
> its more in spirit of nanomsg than authenticating each connection.
>
>
> That's certainly a simpler solution, and it provides gross support for
> "authentication", but it prevents the possibility of using the certificate
> as part of any "authorization" check. I think there may be circumstances
> when its particularly useful to know not only that one client connected
> using a valid cert, but that you know *who* that client is.
>
> Lacking that, you have to perform application layer identity verification.
Not sure what you mean. What you can do with client identity?
You can't send message to that identity anyway, since you send
it to a socket, not a particular client.
You’re thinking in terms of transport routing. We don’t need that — nanomsg
already routes properly at the transport layer. I have no intention of using
this information for making decisions related to the transport (except possibly
— as indicated earlier — access to the transport layer itself.)
The use for client identity is to the *application*, not to the transport layer.
It may be desirable to filter clients by common name, e.g. allow
only "*.workers.example.com", but I don't think that implementing a
callback with client certificate info is a good idea.
Think more like this:
user garrett (verified by his certificate connects to RPC server
running JSON-RPC over REQ socket
he then submits a request: get garrett’s salary
server can see that garrett can get his own salary information, and he
knows the client is an agent acting on behalf of garrett because of the cert.
But if garrett tries to get paul’s salary, the server can check that garrett is
neither paul, nor paul’s manager, nor someone working in accounting or HR, so
the request should be denied.
Those are all *application* layer questions, but having the certificate
information available makes it possible for me to have a high level of
confidence in the identity, which I will use in the application layer for this
kind of policy enforcement.
This is all about making life easier for application developers.
- Garrett
Other related posts:
