Permissions for IoT Things and Cognito User/Identity Pools

Hello,

I am having some issues architecting a good security scheme for managing IoT Thing access for Cognito users. My use case is the following:

• We have a number of users (corresponding to users in a User Pool, with an associated Identity Pool). Each user belongs to a particular "Company". Currently this is done via an attribute (custom:Company).
• We have a number of IoT Things. Each of these Things belongs to a static Thing Group, whose name matches the attribute above.

I'd like for a given User/Identity to be able to receive the MQTT data stream from Things that belong to a static group that matches their custom:Company attribute.

Example:

• I have 6 Things: A, B, C, D, E, F.
• A, B & C belong to static group "FirstCompany"
• D, E & F belong to static group "SecondCompany"
• I have two cognito users/identities: Alice and Bob.
• Alice has the custom attribute custom:Company = FirstCompany
• Bob has the custom attribute custom:Company = SecondCompany

I'd like for Alice to be able to subscribe to the MQTT topics for devices A, B and C, but NOT D, E and F. This means permissions for iot:Connect, iot:Receive, iot:Publish and iot:Subscribe.

The pseudo-policy I'd like to assign to all users is something like this:

effect = allow,
action = ["iot:Receive", ...]
condition: target thing group == ${aws:PrincipalTag/custom:Company}

Unfortunately I haven't found something as straight-forward as this. As I see it, my options are:

1. Draft custom policies for each customer, in which each Thing (and associated topics) are explicitly allowed. This seemingly wouldn't scale well if a customer has thousands of Things.
2. Create a custom IoT authorizer that compares the principal's attribute with the Thing's static group. This seems like it'd run into rate limiting issues, especially if I have to check which groups a Thing belongs to for every MQTT message.
3. Come up with a naming scheme for devices that includes a customer name in some way (e.g., instead of A, B, C I'd have FirstCustomer-A, FirstCustomer-B, FirstCustomer-C). This doesn't feel like a great approach.

However, it seems like this situation would be pretty common! Is there a particular way this should be done? Any guidance would be appreciated!

---

Edit: Following up on the suggestion from Pronoy_C, I've set up the following IoT Core Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": "*"
    },
    {
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:sub": "${iot:Connection.Thing.Attributes[Owner]}"
        }
      },
      "Effect": "Allow",
      "Action": "iot:*",
      "Resource": "arn:aws:iot:us-east-1:xxxxxxxxxxxx:thing/*"
    }
  ]
}

and I've attached this policy both to Thing A and to Alice's Identity. However, while Alice is able to connect to the MQTT host, I cannot publish to $aws/things/A/shadow/get. The AWS logs indicate AUTHORIZATION_FAILURE. I do indeed have the Owner attribute set to Alice's Identity ID. I tried testing with the CLI tool, but have run into issues there (see this thread).