Re: [hono-dev] Qpid Dispatch Router policies

[Chuck Rolke <crolke@xxxxxxxxxx>]

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
>