Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Qpid Dispatch Router Policies

Hi Dominik,

The documentation for policy in Dispatch Router started out as a
doc with drawings. They have yet to be condensed into the book format.
You can see the result at qpid-dispatch/doc/notes/qdr_policy_01.pdf

The "application" is taken from the AMQP Open frame's 'hostname' field.
This is set by the AMQP client. Not all clients set this field the same
way. You may see the IP address of the dispatch router if a client
connects with:

   amqp://192.168.100.100:5672

Then the Open.hostname may contain "192.168.100.100". If this is the
case then the policy will use the ruleset with applicationName
"192.168.100.100".

Clients may override the Open.hostname field or it may be set blank.
A blank policy name is allowed. This is not a mature area of AMQP yet.

An upcoming release of Dispatch Router will allow you to set a single
policy for all connections regardless of the Open.hostname values.

In your specific example you may change the application name to the
IP address of the docker container. Check the Policy logs to see
what application name Policy is seeing when it rejects a connection.

The way your example is putting users into groups and then applying
policy settings to each group is correct and is the intended use.

-Chuck

> > > -------- Forwarded Message --------
> > > Subject: [hono-dev] Qpid Dispatch Router Policies
> > > Date: Tue, 10 May 2016 15:10:21 +0000
> > > From: Guggemos Dominik (INST/ECS1) <Dominik.Guggemos@xxxxxxxxxxxx>
> > > Reply-To: hono developer discussions <hono-dev@xxxxxxxxxxx>
> > > To: hono developer discussions <hono-dev@xxxxxxxxxxx>
> > > 
> > > Hi,
> > > 
> > > I had a look at the policy rulesets that can be defined in the Dispatch
> > > Router configuration with the goal to secure the receiver side of our
> > > telemetry use case.
> > > My first approach was to define an application for the Hono server, a
> > > user group for each tenant with the users that have access to it and set
> > > allowed endpoints for each tenant. With the help of the examples from
> > > the tests I ended up with something like this (I omitted all max*
> > > settings for brevity):
> > > 
> > > [
> > >    [
> > >      "policyRuleset",
> > >      {
> > >        "applicationName": "hono",
> > >        "userGroups": {
> > >          "myTenant": "user1 user2",
> > >          "anotherTenant": "user3 user4"
> > >        },
> > >        "ingressHostGroups": {
> > >          "world": "*"
> > >        },
> > >        "ingressPolicies": {
> > >          "myTenant": "world",
> > >          "anotherTenant": "world"
> > >        },
> > >        "settings": {
> > >          "myTenant": {
> > >            "allowDynamicSrc": true,
> > >            "allowAnonymousSender": false,
> > >            "sources": "telemetry/myTenant",
> > >            "targets": "telemetry/myTenant"
> > >          },
> > >          "anotherTenant": {
> > >            "allowDynamicSrc": true,
> > >            "allowAnonymousSender": false,
> > >            "sources": "telemetry/anotherTenant",
> > >            "targets": "telemetry/anotherTenant"
> > >          }
> > >        }
> > >      }
> > >    ]
> > > ]
> > > 
> > > Now my first question is if this approach is valid and this is how the
> > > policies are supposed to be used?
> > > Apart from that it's not clear to me what the applicationName is used?
> > > Some this resolves to the IP/hostname of the server (in my case the
> > > Docker container)?
> > > 
> > > Best regards
> > > 
> > > Dominik Guggemos
> > > INST/ECS1
> > > 
> > > Tel. +49 7545 202-396
> > > www.blog.bosch-si.com<http://www.blog.bosch-si.com/>
> > > 
> > > 
> > > 
> > 
> 


Back to the top