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
