[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Qpid Dispatch Router policies
|
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-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.
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.
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
