- Newest
- Most votes
- Most comments
Good evening Nicolas!
I read the context behind your question, and the use case is very interesting!
Seems like you were looking for a workaround to the limitations of previously suggested options (- disabling/revoking the device certificate & - changing the policy document), as they do not guarantee immediate traffic interruption from the device.
The extra option I suggest will be 2-folded:
- Create a thing group beforehand (named 'forbidden' for example) and attach a restrictive policy to it (like explicit deny for CONNECT, PUBLISH, SUBSCRIBE, etc). Refer to this guide if needed. This is the group that will include all your forbidden devices.
- Anytime you'd like to deny a specific device, just add it to that forbidden thing group by initiating the corresponding request from your Angular Web App. See the API Reference for guidance.
As the device will just inherit the preexisting restrictive policies from the Forbidden group, the IoT Core message broker will likely acknowledge the change much faster than a certificate policy update (that can be cached for minutes).
On top of that, you'll have all your forbidden devices in a single thing group, allowing further batch actions on them (querying, reporting, certificates revocation, etc).
Let me know if that helps!
Charly.
Relevant content
- Accepted Answerasked 2 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- How can I use a Lambda function to automatically start an AWS Glue job when a crawler run completes?AWS OFFICIALUpdated 2 years ago