Auth for accessing data via digital twin layer
The digital twin layer's APIs are accessible for Solutions
Table of contents:
Business solution: accessing thing data
When your business solution will later try to access data from the digital twin layer, it will need to authenticate with an authorization subject empowered in the thing policy.
The policy can be adjusted to your project needs by adding further entries, and thus empowering other technical clients and users.
For a search or get things request, read thing permissions within the policy should be sufficient.
Business solution: setting desired thing data
When your business solution will later try to send data towards the digital twin layer (e.g. send a new static attribute, which is not relevant for the device), it will need to authenticate with an authorization subject empowered in the thing policy.
The policy can be adjusted to your project needs by adding further entries, and thus empowering other technical clients and users.
For an update (put) thing request, write thing permissions within the policy should be sufficient.
However, with read and write you will be on the safe site for such a scenario (because write does not implicitly include read permission).
For an update (put) policy request, write policy permissions within the policy should be sufficient.
However, with read and write you will be on the safe site for such a scenario (because write does not implicitly include read permission).
By empowering someone else with write policy permission, you risk to potentially be locked out, be it accidentally or by purposes.
In general, the solution owner should be able to manage all policies and should only grant other parties write permission in the things and messages resources but not the policy itself.
Find details on how to Create a policy entry for your backend application.
Device management layer: rules and tasks
Administrative users who define device management tasks and trigger rules for the mass execution of management actions need to authenticate in the scope of the application (e.g. Suite OAuth token).
This token is then used during the task or rule execution and all involved devices will have the permissions listed in the token.
Another option is to have explicit read and write permission (within the thing policy).