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)

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
Microsoft Azure Advisor 

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience


From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of Frank Karsten (INST/ECS4) <Karsten.Frank2@xxxxxxxxxxxx>
Sent: Friday, September 15, 2017 12:50 PM
To: hono developer discussions
Subject: Re: [hono-dev] Topic structure for protocol adapters (MQTT and REST)
 

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

Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im Auftrag von Paolo Patierno
Gesendet: Freitag, 15. September 2017 14:40
An: hono developer discussions <hono-dev@xxxxxxxxxxx>
Betreff: Re: [hono-dev] Topic structure for protocol adapters (MQTT and REST)

 

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

Microsoft Azure Advisor 


Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience

 

From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of Frank Karsten (INST/ECS4) <Karsten.Frank2@xxxxxxxxxxxx>
Sent: Friday, September 15, 2017 10:57 AM
To: hono developer discussions
Subject: Re: [hono-dev] Topic structure for protocol adapters (MQTT and REST)

 

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

Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai (INST/ECS4)
Gesendet: Freitag, 15. September 2017 12:06
An: hono-dev@xxxxxxxxxxx
Betreff: Re: [hono-dev] Topic structure for protocol adapters (MQTT and REST)

 

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

Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai (INST/ECS4)
Gesendet: Donnerstag, 14. September 2017 18:09
An: hono-dev@xxxxxxxxxxx
Betreff: Re: [hono-dev] Topic structure for protocol adapters (MQTT and REST)

 

 

 

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
 

Back to the top