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 
On Do, 2016-09-01 at 12:08 -0400, Chuck Rolke wrote:
> 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.
> 
Just so that I get this straight, the individual router nodes would
then consult the "central" policy server dynamically during runtime ni
order to make authorization decisions, right? I also assume that the
central policy server would take care of persisting the authorization
configuration.

From a Hono perspective, this functionality is more on the short term
wish list since we are currently struggling with the question how we
can make sure to make consistent authorization decisions on the Hono
server and dispatch router instances ...

> 
> ----- 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@bosch-si.c
> > > om>
> > > 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