- Newest
- Most votes
- Most comments
Hi Majh,
you are correct that the disconnect happens when the client breaks the policy. In the specific case, all clients using a clientId different from the Thing Name will break the first policy when trying to publish to abc/MY_THING_NAME/hello. This is because the ${iot:Connection.Thing.ThingName} only resolves to the Thing Name when the the clientId is the same as the Thing Name.
Assuming you really need to have multiple connections using the same certificate - which should only be the case when all connections are established from the same device - then you can use a certificate policy variable instead.
If you are using AWS IoT Certificates you can use a CSR to populate Subject variables when creating the certificate with CreateCertificateFromCsr.
Your policy would then be:
{
"Effect": "Allow",
"Action": [
"iot:Publish"
],
"Resource": [ "arn:aws:iot:ap-pt:xxxxx:topic/abc/${iot:Certificate.Subject.CommonName}/*" ]
}
Cheers,
Massimiliano
Since introduction of the thing-to-connection association also called an exclusive thing association on November 15, 2024, the client ID no longer has to match a thing name. If you want to use a client ID that doesn’t correspond to a thing name, you must attach the device’s X.509 certificate exclusively to a single AWS IoT Thing.
In this setup, your MQTT client can connect to the AWS IoT Core broker using any client ID. Authorization is still enforced by your AWS IoT Core policies, which can reference the associated thing via policy variables.
The exclusive thing association is especially useful when a single certificate needs to support multiple concurrent MQTT connections from the same device.
Relevant content
- asked 5 years ago
- AWS OFFICIALUpdated a year ago
