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