Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Topic structure for protocol adapters (MQTT and REST)

Thanks for putting this together, Karsten :-)

+1 for using this approach

Some (additional) remarks from my side:

I think it is important to understand that we would like Hono to support all of the following types of devices:

1) Devices that need not/can not authenticate to the protocol adapter, e.g. because they are deployed to a strictly private network
2) Devices that do authenticate to the protocol adapter using arbitrary credentials that the device has been provisioned with e.g. during the production process and which
2.1) also know their logical Hono ID
2.2) do not/should not know their logical Hono ID

Using the approach described by Karsten we should be able to easily support all these cases.
Devices of type 1 clearly need to provide the tenant and logical device ID information as part of the topic name (this is what we do today already)
For devices of type 2 the protocol adapter can resolve the logical device ID using the Credentials service. When the device publishes to e.g. "telemetry", the protocol adapter simply uses the resolved device ID when forwarding the data to Hono Messaging. In cases where the device publishes to "telemetry/$TENANT/$DEVICE", the adapter makes sure that the $TENANT and the $DEVICE match the resolved device ID.

NB For the MQTT adapter this means that we no longer require the device to provide its logical device ID in the Client Identifier of its CONNECT packet.

Kai

On 13.09.2017 10:14, Frank Karsten (INST/ECS4) wrote:

Hello to all,

 

after having introduced credentials for the MQTT adapter and soon for the REST adapter as well,

it became obvious that the current structure of topics is not intuitive and even contradictory to the

basic concept of the Credentials API:

not forcing devices to know their "logical device id" when communicating with the adapters.

 

Thus I like to discuss a new concept for the topic structure based on discussions between @sophokles78 (Kai) and @sysexcontrol (me):

 

   publish data to "telemetry" instead of "telemetry/tenantId/logicalDeviceId".

 

 

 

** What is the problem?**

 

Currently, we defined the topic structure "[telemetry|event]/tenantId/deviceId", both for MQTT and for REST. This is fine for the unauthenticated

case, since Hono needs to know where to send data to when a device wants to publish data.

But now we have the credentials API integrated into the MQTT adapter and it became obvious that this topic structure causes problems (being outlined in the following lines).

 

For simplicity, let's focus on how this works for MQTT (REST will be discussed later).

 

The steps for a device are:

 

1.) A device authenticates itself by providing some kind of secret, for example "authId@tenantId/password".

The "authId" (or name it "technicalDeviceId") is usually not the same as the "logicalDeviceId" that is used inside of Hono and the solutions (see Credentials API).

 

- the device opens a MQTT connection and provides the "authId@tenantId/password" which is checked. If not successful, the connection is closed.

- in multi-tenancy configurations, the authId contains the tenantId as well (like "sensor1@myTenant")

 

 

2.) After successful authentication the device wants to publish data. But the question is : to what topic ?

 

- it needs to use the topic "telemetry/tenantId/logicalDeviceId".

- before the publish is accepted, the logicalDeviceId is taken to check with the device registry if the device is enabled

 

3.) And these are the problems:

 

- for publishing, the device needs to know the logicalDeviceId (fatal, since it contradicts to the concept to decouple the device from the logicalDeviceId)

 

- it needs to fill in the same tenant again that was necessary during authentication already (not fatal, but annoying, it did tell Hono the tenantId already, why again?)

 

 

 

** What would be the better solution? **

 

In typical production installations, devices are authenticated first, and Hono knows all it needs for letting the device just publish it’s data.

 

 

So a MQTT device would :

 

- authenticate itself and gets an open connection

- publishes it's data only to "telemetry" or "event" (no need for tenantId or even logicalDeviceId anymore)

- the check with the device registry for the device being enabled still is necessary

 

There is just no necessity anymore for it to fill in already known data: the authenticated device just publishes to "telemetry" or "event". That's it.

 

 

 

** What is the topic structure for installations without authentication? **

 

This use case was the reason for the current topic structure, so there would be no changes to that:

- "[telemetry|event]/tenantId/logicalDeviceId" would still have to be used

 

** How do we handle the same topic for the REST adapter? **

 

For REST I would like to postpone the detailed proposal. It will mainly be a consequence of what we have discussed here (there would be several changes for simplification as well).

Just to not let this point to become even lengthier as it already is.

 

 

 

 

**What is your feedback to that proposal?**

 

Note that it is not only an improvement, partially it is a pure necessity, since the logicalDeviceId must not be known to the device and we need to change that.

 

 

Looking forward to a discussion, feedback, ideas!

 

Thanks,

 

sysexcontrol (Karsten)





_______________________________________________
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


Back to the top