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 Mo, 2016-09-05 at 17:56 -0400, Ted Ross wrote:
> 
> On 09/05/2016 05:24 AM, Hudalla Kai (INST/ESY1) wrote:
> > 
> > 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-49
> > > 4
> > > 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.
> This is correct on both counts.  The consultation to the policy
> service 
> would be done at connection-open time, when a client establishes a 
> connection to a router.  The policy information provided by the
> service 
> would then be cached on the router for fast access during the life
> of 
> the connection.
> 

Would it be possible for other components to retrieve that policy
information as well (e.g. by means of an AMQP receiver on the $policy
resource? I am asking because that would be one option to make sure
that Hono server processes use the same information for making
authorization decisions as the dispatch routers. The other option would
be to make sure that both Hono and the dispatch routers have access to
the same policy persistence store. In any case, we need to start
discussing this in more detail because this is vital for implementing
security in Hono efficiently.

Where is the right place to start a discussion of options for he
dispatch router? Would it make sense to create a JIRA issue for this?

> > 
> > 
> > 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
> > _______________________________________________
> > 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