Hi all,
Question 1
do we need the authId at all?
or is it always identical to the logicalDeviceId?
à I see no reason for a specific authId
and I am not aware that other MQTT IoT solutions need one. Maybe better expand our concept, when we see a reason (or of course if you see one, now)?
Question 2
What is the exact role of a gateway that bundles southbound devices?
à I think we should not think about
devices behind a gateway. Only about how gateways authenticate themselves and how they are authorized to send data in the name of a device. We do not know how devices are connected to the gateway and which types of authentication the devices can provide.
So it is your alternative 1 – but it does not need, that device know something – only the that the gateway can provide the needed information.
Question 3
Do we want a gateway concept in Hono at all?
à I think we only need a gateway concept
in that way, that we authorize some “devices” (gateways) to publish as n other devices.
Question 4
Shall we support STAs as alternative or forget about them?
à I would like to have only one, and
this need to be FQTA.
Mit freundlichen Grüßen / Best regards
Marc Pellmann
(INST/ECS4)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx]
On Behalf Of Frank Karsten (INST/ECS4)
Sent: Montag, 18. September 2017 16:21
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Topic structure for protocol adapters (MQTT and REST)
Hi all,
I think we are getting close to a good topic address structure for all Use cases! But there are still open points (see the end of this mail).
Here is the summary of all previous discussions that does not repeat all use cases or agreed on questions again:
General:
- focussing on MQTT and multi tenancy only
- Devices always know their tenantId and
either know their logicalDeviceId or their authId
- MQTT clients can always use the username/password feature of the protocol
- Wording: let me define two abbreviations for our topic address structure
-
STA: Simple Topic Address like "/telemetry"
-
FQTA: Fully Qualified Topic Address like "/telemetry/tenantId/logicalDeviceId"
Topic addresses:
Devices (southbound)
- with authentication:
- FQTA: /telemetry/tenantId/[authId|logicalDeviceId]
- STA: /telemetry
- username: [authId|logicalDeviceId]@tenantId
- without authentication:
- FQTA: /telemetry/tenantId/logicalDeviceId
Gateways (southbound)
- with authentication:
- FQTA: /telemetry/tenantId/[authId|logicalDeviceId]
- STA: /telemetry : only possible if authentication info for the device is added to the payload
- username: gatewayAuthId@tenantId
- without authentication:
- FQTA: /telemetry/tenantId/logicalDeviceId
Solutions (northbound)
- always FQTA: /telemetry/tenantId/logicalDeviceId (never authId)
Configuration of protocol adapters:
- force southbound authentication per tenant (and not per adapter instance)
To be further discussed:
Question 1
do we need the authId at all?
or is it always identical to the logicalDeviceId?
I think we need the authId, but am not 100% sure. WDYT?
Question 2
What is the exact role of a gateway that bundles southbound devices?
Since the authentication is done during connection setup in MQTT, it has to authenticate with some “gatewayId@tenantId” as username.
But how about the devices then?
1)
Alternative 1: devices always have to know their logicalDeviceId when they are behind a gateway:
The gateway then uses the FQTA and all is fine. Hono needs to trust the gateway to do the right thing of course, so there needs
to be some “super” rights for gateways to publish to arbitrary topics.
2)
Alternative 2: the gateway resolves the devices “authId” by accessing the Credentials API of Hono (not my favourite) and then uses the logicalDeviceId
in the FQTA for each device.
The gateway then has significant complexity of accessing the Credentials API and needs to have access to that. Sounds _very_ demanding.
3)
Alternative 3: gateways put the authentication information of the device into the payload. The protocol adapters then need to do the authentication for
each device and resolves the logicalDeviceId and publishes the payload to the FQTA.
I strongly vote against Alternative 2, and think Alternative 1) and 3) may both be necessary. WDYT?
Question 3
Again gateways:
Do we want a gateway concept in Hono at all?
1)
Alternative 1): we do not have a gateway concept. So the gateway is like a normal “power device” that publishes all device payloads to the FQTA of the
gateway itself. The solution needs to be aware of gateway topologies. The only difference for Hono is that the gateways publish much more data then single devices would.
2)
Alternative 2): we have a gateway concept and define that solutions never need to be aware of gateways bundling lots of devices – they get the data as
all devices would be connected individually to Hono.
I vote for 2). WDYT?
Question 4
Shall we support STAs as alternative or forget about them?
I propose to turn around the defaults: in authenticated use cases they can be used, but the usual and mainly documented way are the FQTAs.
WDYT?
Mit freundlichen Grüßen / Best regards
Karsten Frank
INST/ECS4
Tel. +49 30 726112-403
Sorry, that was an accidental hit of the return button ;-)
I will post a complete excerpt/summary of all points of the discussion soon!
Mit freundlichen Grüßen / Best regards
Karsten Frank
INST/ECS4
Tel. +49 30 726112-403
Mit freundlichen Grüßen / Best regards
Karsten Frank
INST/ECS4
Tel. +49 30 726112-403
I'm not worried about having a different topic format between what we expose by adapters and what we have internally (even if having an AMQP adapter for the AMQP protocol will sound
always weird to me :-)).
I'm not worried about having a client providing same information more time. From my experience it happens in the Azure IoT Hub as well (with MQTT). The device-id is used in the client-id
field, in the username and finally in the topic :-). Of course I don't know the internals so why it's duplicated in the username as in the client-id.
I'm worried about giving to other developers working on IoT solutions a consistent way in different use cases to send data/receive commands and so on.
I think that the complexity we have here is the fact that we are considering to have two different id : an auth-id and a logical-id. Afaik it's something that other IoT solutions doesn't
have so they speak only about "device-id". Maybe it's also true because all of them offers only the authenticated way.
Looking forward to your summary Karsten !
Thanks for driving this useful discussion !
Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Ok, that could be a good idea and would of course be technically possible.
But I like to ask the question again: what is more important to us?
a)
Have all topics sticking to one pattern (3 segments for all use cases without exception)
b)
Not forcing devices to provide already known data (like tenant and authId/logicalDeviceId) again
Considering that the topic format for protocol adapters still would sometimes differ from the topic format for Hono Downstream AMQP endpoint
I find point a) still not so simple to understand:
Device publishes to “telemetry/tenantId/authId”, but the protocol adapter and Hono messaging deliver to “telemetry/tenantId/logicalDeviceId” for the AMQP based solution.
It seems currently we have not found the simple, fully working solution for all use cases, have we?
Will do a short summary next week again with only topics per use case since I think we all have the same understanding of the use cases now.
Thanks for this idea, Paolo!
Mit freundlichen Grüßen / Best regards
Karsten Frank
INST/ECS4
Tel. +49 30 726112-403
Maybe it could be the authid instead of the logicalid ?
So : /telemetry/tenant_id/[auth_id | logical_id]
Of course the device should provide the authid in the password as well (as you described in the case 1).
Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
The problem is that in Use case 1 the devices usually would not be able to use the “telemetry/tenantId/deviceId” topic format, since they never know their “deviceId”,
but only their “authId”.
So I am afraid we do not have the option to make this mandatory, but have to (also) support the simple topic “telemetry”.
The optional usage of “telemetry/tenantId/deviceId” is only for devices that know their deviceId (in Use case 1 additionally to their authId, sometimes they might be
identical e.g.).
Or am I missing something?
Mit freundlichen Grüßen / Best regards
Karsten Frank
INST/ECS4
Tel. +49 30 726112-403
At this point I agree with Kai on having the /telemetry/tenatid/deviceid as topic format even for the case 1 but not as an alternative to /telemetry but as mandatory.
At least, in this way we "lost the dream" of having a simple /telemetry topic format but we have a consistent /telemetry/tenantid/[auth|logic]id topic format for all the use cases.
Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Ok, I see the point – since it is easy to implement anyway, we then should allow both versions.
Mit freundlichen Grüßen / Best regards
Karsten Frank
INST/ECS4
Tel. +49 30 726112-403
Well, this might make implementation of the client easier, because it will simply always use the long version. No need to distinguish. Maybe some developers do not find it worth the
effort to distinguish between authenticated and unauthenticated just to save a few bytes in the message(s) ...
On 15.09.2017 11:09, Frank Karsten (INST/ECS4) wrote:
Hi Kai,
+1 for Adapter configuration Alternative 3 : configuration per tenant. That is my favourite as well.
+1 for Use Case 4 “unauthenticated gateway” which is just another usage of Use Case 2 (so I skip to ignore this use case).
But to Use Case 1: the value of letting the authenticated device publish to “telemetry” OR “telemetry/tenantId/deviceId” is not clear to me.
Why should a device want the long version of the topic address when this is even checked against the credentials again?
Mit freundlichen Grüßen / Best regards
Karsten Frank
INST/ECS4
Tel. +49 30 726112-403
On 14.09.2017 14:54, Frank Karsten (INST/ECS4) wrote:
Hi all,
let me try to summarize what alternatives the IMHO quite valuable discussion brought so far.
At the end I voted for my favourite alternatives, maybe you can do the same so that we then only continue to discuss the points where we could not agree on.
All comes down to the questions:
-
Do we support authtenticated / unauthenticated devices at the same time?
-
Single devices vs. gateways acting for a set of devices
-
Same topic address for all use cases or different ones?
********************
Goal:
Define a topic address scheme for our protocol adapters with following principles:
- as simple as possible (no doubled information like tenantId or deviceId)
- intuitive
- secure
- supporting gateways (== act "on behalf" of sets of devices)
- receivers of device data do not need to know if the device was first handled by a gateway (and probably cannot know either)
Remarks:
- not to be confused with the Hono AMQP topic structure (remains unchanged)
- we focus on MQTT first (and apply the result to HTTP also then)
- we focus on telemetry (event endpoint is treated the same)
- we focus on multi tenancy (single tenancy should be straightforward)
MQTT adapter specific principles:
- not using the clientId for any Hono specific data (like deviceId)
- using username/password of MQTT (where appropriate)
- we expect that ALL MQTT clients support the usage of username/password
********************
Use Cases:
********************
Use Case 1) Single device authenticated
Topic scheme: "telemetry"
Username: authId@tenantId
Password: <password>
No alternatives.
I would also like to allow a device to use the "telemetry/$TENANT/$DEVICE" form, in which case the given tenant and device IDs must match the credentials.
Use Case 2) Single device unauthenticated
Alternative 1:
Topic scheme: "telemetry"
Username: logicalDeviceId@tenantId
Variants to distinguish from authenticated use case:
a) no password (as detection of this use case)
b) explicitly configured for whole adapter (exclude authenticated use case for all devices)
Alternative 2:
Topic scheme: "telemetry/tenantId/logicalDeviceId"
No username, no password
Use Case 3) Gateway device authenticated
Username: gatewayAuthId@tenantId
Password: <password>
Alternative
1:
Topic scheme: "telemetry/tenantId/logicalDeviceId"
The gateway has to publish messages by constantly changing this topic, depending on
for which device the payload has to be transfered.
We need a permission mechanism for gateways to allow this.
Alternative 2:
Topic scheme: "telemetry"
The gateway sends payloads from multiple devices.
The protocol adapter needs to make single AMQP messages to Hono from that (one for each device payload).
Use Case 4) Gateway device unauthenticated
can be ignored IMHO. Should not be supported.
This is the same as Use Case 2, Alternative 2
********************
Adapter configurations:
********************
Do we support authenticated and unauthenticated devices/gateways in one adapter at the same time?
Alternative 1
:
unauthenticated devices need to be configured as adapter property (considered as test scenarios only)
Mo mixed scenarios for a single adapter instance supported.
Alternative 2:
Adapters always support unauthenticated and authenticated devices / gateways at the same time.
Directly leads to security problems IMHO (attacks to guess the logicalDeviceId).
Alterative 3: requiring authentication can be configured per tenant
********************
Vote:
I vote for the following strategy:
Use Case 1: “telemetry” - nothing to vote, all is clear
+1
Use Case 2: Alternative 2) "telemetry/tenantId/logicalDeviceId" with b) explicit adapter config
Alternative 2) but with c) configuration per tenant
Use Case 3: Alternative 1) "telemetry/tenantId/logicalDeviceId" for authenticated gateways
1+
Use Case 4: do not support it
this use case will be supporte implicitly because it is the same as UC 2 with alt. 2
Adapter Config: Alternative 1) expicit config, no mixture for single instances
configuration per tenant
Thanks if you read so far down, I could not compress it further ;-)
Mit freundlichen Grüßen / Best regards
Karsten Frank
Senior Software Developer
Bosch Software Innovations GmbH
Development Core Products (INST/ECS6-Be)
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr.-Ing. Rainer Kallenbach, Michael Hahn
_______________________________________________
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
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr.-Ing. Rainer Kallenbach, Michael Hahn