Hi,
I'm not entirely convinced yet. We are creating an AMQP API and I'm not sure if it's a good idea to align our API to the
peculiarities of a single client (in this case the Qpid JMS Client). I think in the first place we should provide a clean AMQP API design (independent of implementations) and then add alternatives for clients if required. Perhaps this can be combined with
the policy-based approach Dejan suggested, which could mean that the JMS Client only supports the medium and loose policy? What I would like to avoid is that all clients have to go the JMS way just because the JMS client has some restrictions.
Apart from that, do you think we should go for the policy approach in our first milestone or implement one of the policies
mentioned and extend it in future milestones? If we choose the latter which "policy" should we implement now? I'm asking this because I'm stuck implementing this currently, see [1]
[1]
https://github.com/eclipse/hono/issues/7
Mit freundlichen Grüßen / Best regards
Dominik Guggemos
Bosch Software Innovations GmbH
Engineering Cloud Services (INST/ECS1)
Ziegelei 7
88090 Immenstaad
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Tel. +49 7545 202-396
Fax +49 7545 202-301
dominik.guggemos@xxxxxxxxxxxx
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx]
On Behalf Of Dejan Bosanac
Sent: Monday, June 06, 2016 4:23 PM
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Telemetry & Device Registration API
Yeah, I think we should do per-message authorisation in a system like this. Maybe we can make this policy-based, like
- strict - require client authorisation against the address upfront
- medium - allow anonymous relay, drop connection on a first unauthorised message
- loose - allow anonymous relay and just drop unauthorised messages
I don’t like overcomplicating things, but that’s usually the price for flexibility.
On Mon, Jun 6, 2016 at 1:19 PM, Kai <sophokles.kh@xxxxxxxxx> wrote:
You are right, Dejan. We are already authorizing every message (and I think we need to). We could do what you seem to propose, i.e. let clients connect to an anonymous relay and send messages to whatever address they want to and filter out unauthorized messages
or drop the connection if a client sends a message to an address it is not authorized for.
I’m just thinking if we do this, we’d need to do authorisation on every message. Which is basically the same case as if we don’t specify target address in the first place.
What if we allow producers to connect with /telemetry/${tenent-id}/${device-id} and authorise only on tenant-id? We’re in control over this and the producer is locked on which destinations it can send?
On Mon, Jun 6, 2016 at 10:42 AM, Gordon Sim <gsim@xxxxxxxxxx> wrote:
On 06/06/16 08:33, Hudalla Kai (INST/ESY1) wrote:
Hi,
Dominik and I have played around with the Qpid JMS client for AMQP 1.0
and came across the following issue:
The JMS API requires a client to create a MessageProducer by means of a
Session, e.g. by invoking Session.createProducer(Destination). If the
given Destination object is null, the client can use the producer to
send messages to arbitrary addresses. However, if the Destination is not
null, the client can use the producer only to send messages to the
Destination's address.
This is a problem with our current approach of using the "to" field of
an AMQP message to convey the tenant and device IDs (as opposed to
providing these values in separate header fields). We require Hono
clients to connect to Hono with a target address of e.g.
"/telemetry/${tenant-id}" in order to authorize the client for the given
tenant. However, if a JMS client uses Destination with this address for
creating the MessageProducer, it cannot set the address on messages sent
via this producer anymore (because the JMS spec explicitly prohibits this).
The way I see it, we can either drop the requirement to connect to Hono
with a target address indicating the endpoint and tenant or we need to
fall back to the client providing the tenant and device IDs in header
fields (again).
AFAIK I prefer the latter option because I think it would be unwise to
prevent clients to use JMS to connect to Hono (mainly because the only
reasonably usable AMQP 1.0 Java client seems to be Qpid JMS at the moment).
What do you think?
I agree with you. If full control over the 'to' field is not possible, it is better to use a custom field.
BTW we are facing the same problem with Hono's other API's as well, e.g. [1]
[1] https://github.com/eclipse/hono/issues/7
_______________________________________________
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
--
|
