Bosch IoT Device Management


This section holds information about the emitters of messages (where you get messages from).

Multiple sources are supported.

The sources are identified by a queue name (AMQP 0.9.1) or a source (AMQP 1.0), thus this field will allow any string.

Example: telemetry/<hub-tenant-ID>


In case a fixed authorization subject is not flexible enough for your scenario (e.g. you don’t want to grant one authorization subject WRITE access to all things), placeholders can be used in the configuration of a source to allow more fine-grained per-device access control.

Given that the message headers contain some information about the origin (e.g. a device ID), you can specify the authorization subject as follows:
integration:<solution-id>:{{ header:device_id }}”.

The placeholder {{ header:device_id }} is replaced by the value from the headers and the message is further processed under this authorization subject. If the specified header cannot be resolved, the sender receives an error response (if a reply-to header was given), or dropped otherwise.


Messages received from external systems are mapped to the Bosch IoT Things service internal format for further processing, either by applying some custom mapping or the default mapping for Ditto protocol messages. During this mapping the specific thing which is accessed or modified as a result of the message is determined.
By default no sanity check is done if this thing corresponds to the device that originally sent the message. For some use cases this might be valid, but in other scenarios you might want to enforce that a device only sends data to its associated thing.

Note that this could also be achieved by assigning a specific policy to each thing and using placeholders in the authorization subject. However, this can get cumbersome to maintain for a large number of things.
With an enforcement, you can use a single policy for all things and still make sure that a device only modifies its associated thing representation (aka digital twin).

Enforcement is only feasible if the message contains the verified identity of the sending device (e.g. in a message header). This verification has to be done by the external system e.g. by properly authenticating the devices and providing the identity in the messages sent to Ditto.

Currently enforcement can be enabled for Hub/AMQP 1.0 and AWS IoT/MQTT connections.