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

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

Back to the top