Re: [hono-dev] Qpid Dispatch Router Policies

[Ted Ross <tross@xxxxxxxxxx>]

Hi Dominik,

We are planning to include the policy-default enhancement in the next 
release candidate for 0.6.0.

-Ted

On 05/11/2016 08:29 AM, Guggemos Dominik (INST/ECS1) wrote:
> Hi Chuck,
>
>
>
> thanks for your explanation and the pointer to the policy documentation, that helped a lot.
>
> We noticed there's already a discussion about this topic on the Qpid users mailing list<http://qpid.2158936.n2.nabble.com/Dispatch-access-control-policy-what-is-the-idea-behind-applicationName-tp7643479.html>.
>
>
>
> > > An upcoming release of Dispatch Router will allow you to set a single policy for all connections regardless of the Open.hostname values.
>
>
>
> Do you think this will make it into the upcoming 0.6.0 version?
>
>
>
> Regards,
>
> Dominik
>
>
>
> -----Original Message-----
> From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] On Behalf Of Chuck Rolke
> Sent: Tuesday, May 10, 2016 8:25 PM
> To: hono-dev@xxxxxxxxxxx
> Subject: 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<mailto:Dominik.Guggemos@xxxxxxxxxxxx>>
>
> > > > Reply-To: hono developer discussions <hono-dev@xxxxxxxxxxx<mailto:hono-dev@xxxxxxxxxxx>>
>
> > > > To: hono developer discussions <hono-dev@xxxxxxxxxxx<mailto: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/<http://www.blog.bosch-si.com%3chttp:/www.blog.bosch-si.com/>>
>
> > > >
>
> > > >
>
> > > >
>
> > >
>
> >
>
> _______________________________________________
>
> hono-dev mailing list
>
> hono-dev@xxxxxxxxxxx<mailto:hono-dev@xxxxxxxxxxx>
>
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/hono-dev
>
>
>
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev