search

eclipse-hono / hono

Eclipse Hono™ Project
https://eclipse.dev/hono
Eclipse Public License 2.0
450 stars 139 forks source link

Support for gateways reporting data on behalf of other devices #416

Closed zubairhamed closed 6 years ago

zubairhamed commented 6 years ago

For example, devices which are proxied by an HTTP server (or the typical Gateway pattern for non-ip devices)

Currently it looks like a 1:1 mapping between auth-id and device-id

I understand that POST omits the tenant and device-id from the path.

How can multiple devices use the same auth-id to authenticate? Combine Basic Auth with the PUT request instead?

sophokles73 commented 6 years ago

A device within Hono is defined by its (unique) (tenant ID, device ID) tuple. That said, a particular device can have arbitrary authentication IDs associated with it (using the Credentials API). This accounts for use cases where a device is capable of using multiple transport protocols (and authentication mechanisms) or rotating keys. However, when a device connects to a protocol adapter and gets authenticated, its device ID is resolved based on the credentials (auth ID + secret) the device provides. Thus, if two devices use the same credentials during authentication, they are resolved to the same device ID, i.e. Hono treats them as the same device. With gateways there are two scenarios possible:

  1. The gateway acts on behalf of the sensors attached to it, i.e. each sensor is represented by its own device ID in Hono and the gateway effectively acts as a proxy only and is not represented by a device ID in Hono.
  2. The sensors attached to the gateway are managed as resources or properties of the gateway itself but only the gateway is represented by a device ID in Hono. The Eclipse Kura gateway for example follows this approach.
zubairhamed commented 6 years ago

Hi Kai,

I’m referring to more like the pattern of actual devices which are non ip enabled and needs the use of a gateway to proxy them.

Think of Example Zigbee where nodes should be identified by devices but the gateway could be using a single username or password(or certificate auth)

Z

sophokles73 commented 6 years ago

Still, this might be accomplished using any of the approaches outlined above. Which one are you referring to? Do the ZigBee devices/sensors need to be represented by their own device ID or are they mapped to properties of the gateway, so that when such a ZigBee device has some data to publish, it would appear as if it came from the gateway?

zubairhamed commented 6 years ago

Yes exactly. Each Zigbee (or any other typical similar protocol)device would be its own device and would need its own Device ID.

sophokles73 commented 6 years ago

Each Zigbee (or any other typical similar protocol)device would be its own device and would need its own Device ID.

Is that a hard requirement or is this just the first approach that came to mind? Would it also work to map the ZigBee devices to properties of the gateway?

zubairhamed commented 6 years ago

Its a hard requirement, such devices have their own pairing, commissioning process etc so they shouldn't be compared to data/sensors.

Also LPWAN technologies (LoRAWAN/Sigfox) where you typically configure a single backend callback of device "types" and not devices would be affected.

If you're available later after lunch for f2f, i can show you exactly what i mean.

Z

sophokles73 commented 6 years ago

I see. Then the answer is: no, Hono does not support this use case at the moment. The protocol adapters currently do not support a client to act on behalf of other devices. We have been giving this some thought but it would probably require some more sophisticated authorization model than what we currently have in place.

sophokles73 commented 6 years ago

One possible approach to the use case where a gateway acts on behalf of another device:

  1. The gateway connects to adapter and provides credentials for authenticating the gateway, the gateway also includes tenant and device ID of the device it wants to report data for (e.g. in a header or the request URI)
  2. The adapter authenticates the gateway in the usual way
  3. The adapter asks the Device Registration service to issue a registration assertion for the impersonated device. For that purpose we add a new variant of the assert device registration operation to the Device Registration API which takes as input both the gateway's (tenant-id, device-id) tuple and the impersonated device's (tenant-id, device-id) tuple.
  4. Based on the data on record, the Device Registration implementation can determine, if the gateway is allowed to act on behalf of the impersonated device and issue the token for the impersonated device.
  5. The adapter can then proceed as usual, i.e. forward the data including the token to Hono Messaging.

This way we could gradually introduce support for this kind of gateway operation by

  1. introducing the additional operation to the Device Registration API
  2. providing a default implementation in the Device Registry component which always denies the token
  3. adapting the protocol adapters to support this kind of gateway operation
  4. adding support for defining relations between gateways and devices in Device Registry and issuing tokens based on the existence of such a relation.
zubairhamed commented 6 years ago

@sophokles73 The approach you've illustrated sounds good.

sophokles73 commented 6 years ago

fixed in 95407c4c4d32ac31fdfceebc8e4fbaf1a3eed81c