Sources
This section holds information about the emitters of messages (where you get messages from).
For a Kafka connection, the source addresses are Kafka topics to subscribe to. All messages are consumed in an "At-Most-One" manner. This means that the offset will be committed after the message was consumed from Kafka, no matter if the message can be processed correctly or not.
Multiple sources are supported.
Examples:
Source 1 Addresses hono.telemetry.t
Source 2 Addresses hono.event.t
Source 3 Addresses hono.command_response.t
Placeholders
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.
Enforcement
Currently enforcement can be enabled for Hub/AMQP 1.0 and AWS IoT/MQTT connections.
Messages received from external systems are mapped to the digital twin layer 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.
Placeholders supported for connection sources
A connection will consume commands and messages from the sources configured within the connection.
A source configuration comprises the address and the authorization.
Find examples at https://www.eclipse.org/ditto/basic-placeholders.html