You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think right now only {iot:ThingName} is possible.
Use Case
We have following setup in place:
LocalDevices -> CoreDevie ( EMQX and MQTT Bridge in place) -> IoTCore
In coredevice's policy we use variables to restrict topics to coredevies attributes e.g. arn:aws:iot:eu-central-1:123456789012:topic/cfg/${iot:Connection.Thing.Attributes[id]}/info/*
Right now we can restrict topics at client device auth component with wildcards which is ok if localDevice sends to a topic that is totally wrong but not if it used the wrong id inside the right topic. So if this is the case the policy will only be evaluated at IoT Core level and only coredevice will get notified that this topic is not allowed.
Better would be if we could use the attribute as policy variable in the client device auth config and so the local device gets blocked there and notified that the topic is not allowd.
Hope you understand my use case.
Regards, Marco
The text was updated successfully, but these errors were encountered:
Yep, only thing name substitution is available in CDA right now. Thing attr support is in our backlog; I can't say for sure when we'll be able to get around to it, but I'll bring it up with the team again
Feature Description
Would it be possible to use or implement the use of Thing Attributes as policy variables?
Example: {iot:Connection.Thing.Attributes[SomeAttribute]}
I think right now only {iot:ThingName} is possible.
Use Case
We have following setup in place:
LocalDevices -> CoreDevie ( EMQX and MQTT Bridge in place) -> IoTCore
In coredevice's policy we use variables to restrict topics to coredevies attributes e.g.
arn:aws:iot:eu-central-1:123456789012:topic/cfg/${iot:Connection.Thing.Attributes[id]}/info/*
Right now we can restrict topics at client device auth component with wildcards which is ok if localDevice sends to a topic that is totally wrong but not if it used the wrong id inside the right topic. So if this is the case the policy will only be evaluated at IoT Core level and only coredevice will get notified that this topic is not allowed.
Better would be if we could use the attribute as policy variable in the client device auth config and so the local device gets blocked there and notified that the topic is not allowd.
Hope you understand my use case.
Regards, Marco
The text was updated successfully, but these errors were encountered: