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 
The create/update/delete functions are now committed on the
master branch and will be available in the next release.

Example code is in function test_verify_policy_add_update_delete() in
https://github.com/apache/qpid-dispatch/blob/master/tests/system_tests_policy.py

-Chuck

----- Original Message -----
> From: "Chuck Rolke" <crolke@xxxxxxxxxx>
> To: "hono developer discussions" <hono-dev@xxxxxxxxxxx>
> Sent: Thursday, September 1, 2016 12:08:53 PM
> Subject: Re: [hono-dev] Qpid Dispatch Router policies
> 
> Sorry for misinformation but the Policy and Vhost objects do not have
> the code to support Update and Delete operations. This is a code
> maturity issue. https://issues.apache.org/jira/browse/DISPATCH-494
> created to make sure this gets done.
> 
> The longer term goal for policy in dispatch router is to have
> a policy server (at address $policy) to govern policy for the
> router network. Then individual routers would consult $policy
> as needed to allow/deny connections and to get limits for the
> connection.
> 
> 
> ----- Original Message -----
> > From: "Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>
> > To: hono-dev@xxxxxxxxxxx
> > Sent: Thursday, September 1, 2016 11:50:04 AM
> > Subject: Re: [hono-dev] Qpid Dispatch Router policies
> > 
> > On Do, 2016-09-01 at 10:52 -0400, Chuck Rolke wrote:
> > > Hi,
> > > 
> > > The policies are completely manageable using the normal qdmanage
> > > channels. The policy self tests unfortunately do not illustrate how
> > > to create or to update a policy object through application code. One
> > > half the the equation, using qdmanage to get a policy object, is
> > > shown in tests/system_tests_policy.py
> > > test_verify_policies_are_loaded()
> > > 
> > >         rulesets = json.loads(self.run_qdmanage('query --
> > > type=vhost'))
> > >         self.assertEqual(len(rulesets), 5)
> > > 
> > > The run_qdmanage function returns a json string that holds the object
> > > in question. The string may be modified as desired and sent back to
> > > the router as a management request. I will create a self test that
> > > does just that.
> > 
> > Thanks for clarifying, Chuck. My understanding is that this update
> > would then need to be performed on all dispatch router instances (of a
> > cluster/network) separately, right?
> > 
> > Orchestrating such an update across a large population of dispatch
> > router instances doesn't seem a trivial task to do AFAIK. You could
> > argue that a re-configuration nowadays (in the Docker/cloud era) would
> > encompass building a new image (with the updated configuration) instead
> > of changing the config during runtime and then ripple-update all
> > instances, i.e. shut down an old instances and replace it with a new
> > instance (with the new config) one by one.
> > 
> > Is that how you envision it?
> > 
> > Another way could be to introduce support for a config server (e.g.
> > etcd or consul) into dispatch router so that the config could be
> > managed centrally and each instance would get their config from there
> > ...
> > 
> > > 
> > > In the code today updates to policy objects are NOT applied to
> > > existing connections, only to new connections. Connections cache the
> > > policy settings at the time the connection is created and use them
> > > for the lifetime of the connection.
> > > 
> > > Regards,
> > > Chuck
> > > 
> > > 
> > > From: "Guggemos Dominik (INST/ECS1)" <Dominik.Guggemos@xxxxxxxxxxxx>
> > > To: "hono developer discussions" <hono-dev@xxxxxxxxxxx>
> > > Sent: Thursday, September 1, 2016 5:13:15 AM
> > > Subject: [hono-dev] Qpid Dispatch Router policies
> > > 
> > > Hi all,
> > >  
> > > after having a closer look at the Qpid Dispatch Router configuration
> > > regarding authentication and authorization there are some questions I
> > > would like to discuss.
> > > Our current architecture approach [1] involves that clients need to
> > > be authenticated and authorized at both endpoints (Hono server and
> > > Dispatch Router). As a result we need to keep this information in
> > > sync between them. For the authentication this should be doable by
> > > using the same SASL provider and  the same source of information e.g.
> > > database (Kai is working on the SASL topic already). For the
> > > authorization it’s not that simple. As I understand for the Dispatch
> > > Router the information e.g. who is allowed to attach to a
> > > source/target (the policies) is rather static. I found no way to
> > > modify this data during runtime of the router, is this correct? Are
> > > there any plans to make this more flexible? Or more generally, how
> > > are the policies are supposed to be used if I want to grant a new
> > > user access to the router or revoke access of an existing user
> > > (without restarting the router)? Maybe an example of how this is done
> > > in existing systems helps to understand.
> > >  
> > > [1] https://github.com/eclipse/hono/wiki/Topology-Options
> > >  
> > > Best regards
> > >  
> > > Dominik Guggemos
> > > INST/ECS1
> > >  
> > > Tel. +49 7545 202-396
> > > www.blog.bosch-si.com
> > >  
> > > 
> > > _______________________________________________
> > > 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
> > > 
> > > _______________________________________________
> > > 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
> > _______________________________________________
> > 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
> > 
> _______________________________________________
> 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
>

Back to the top