Scaling authorization policies with AWS IoT Core

Question

The number of policies that can be attached to a Amazon Cognito identity is 10. This means that our customers are limited to a maximum of 10 devices.

I read a solution suggestion to solve this in the below document:
https://aws.amazon.com/tr/blogs/iot/scaling-authorization-policies-with-aws-iot-core/

Multiple device topics into a single policy.
For publish and receive actions (85 characters):

```
arn:aws:iot:us-east-1:123456789012:topic/$aws/things/cheryl-kitchen-light-01/shadow/*
```

But I am using the jitr method. This doesn't seem appropriate to me.

on https://docs.aws.amazon.com/general/latest/gr/iot-core.html:
Maximum number of policies that can be attached to a certificate or Amazon Cognito identity:  default value is 10 : not adjustable

What should I do in this situation?

Answer

Policy variables are a way to scale one IoT policy to many devices:

https://docs.aws.amazon.com/iot/latest/developerguide/basic-policy-variables.html
https://docs.aws.amazon.com/iot/latest/developerguide/example-iot-policies.html
https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html

The blog you reference uses wildcards and partial topic matching to achieve similar.

Please also refer to this whitepaper: https://docs.aws.amazon.com/whitepapers/latest/designing-mqtt-topics-aws-iot-core/designing-mqtt-topics-aws-iot-core.html

And particularly: https://docs.aws.amazon.com/whitepapers/latest/designing-mqtt-topics-aws-iot-core/mqtt-design-best-practices.html

I think this quote may be of interest to you:

> Consider using Named Shadows to create logical groups of properties. You can create a unique access policy for each Named Shadow, therefore controlling what applications or services can view or update that group of properties. An example of this would be the device management team viewing the firmware, battery health, or WiFi signal strength but not having access to the data being published by the sensors on said devices.

Named shadows didn't exist when that blog was published. With named shadows you could use a policy variable for the thing name and reference the shadow name explicitly.

Answer

As noted in your question, the approach described in the blog post you have referred to does not work with the JITR/JITP process, as it requires knowing the user claiming the device at the time of the device onboarding.

A possible solution is two have a 2 step process: first, as the device is powered up and connected to Internet, it gets automatically onboarded in AWS IoT Core via the JITP/JITR process. At this stage, your device will be represented with a thing using a unique device id as thing name and will have a unique certificate. In order to avoid consuming any of the 10 directly attachable certificate policies, you can leverage Thing Group IoT Policies (https://docs.aws.amazon.com/iot/latest/developerguide/thing-groups.html#group-attach-policy) creating a generic policy that uses ioT policy variables and attaching that to the thing group. The device thing is then attached to the thing group. Let's call it `unclaimed` group.

Example policy to be attached to the Thing Group that allows the device to only process claiming messages, ie not being fully functional:

```
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action":["iot:Subscribe"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:topicfilter/claimed/${iot:Connection.Thing.ThingName}"]
      },
     {
        "Effect": "Allow",
        "Action":["iot:Publish"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:topic/claimed/${iot:Connection.Thing.ThingName}/confirmed"]
      },
      {
        "Effect": "Allow",
        "Action": ["iot:Connect"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"]
      }
    ]
}
```

In a second phase a user claims the device via a companion app you are providing. At this point you:

1.  create a new Thing according to the naming convention described in the blog post (eg `-`)
2. attach the thing to a `claimed` Thing Group which has a policy allowing the device full operations
2. attach the existing device certificate to the new Thing you created
3. send a message to the device to communicate the new thing name
4. the device responds back confirming it has gotten the new name
6. the device reconnects with the new thing name as clientId

In addition, the CognitoId principal for the user has a policy attached that allows it to connect to IoT Core and communicate with all devices matching the `` prefix. This policy is created when the user creates the account on your platform.

Example of the IoT policy attached to the Cognito id principal:
```
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action":["iot:Subscribe"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:topicfilter/*"]
      },
     {
        "Effect": "Allow",
        "Action":["iot:Publish"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:topic/*"]
      },
      {
        "Effect": "Allow",
        "Action": ["iot:Connect"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"]
      }
    ]
}
```

This said, if your solution is about having a users being able to control multiple devices via an application I would advice to use the approach described in this blog post https://aws.amazon.com/blogs/iot/connecting-home-appliances-with-a-smart-home-solution-built-on-aws-in-the-aws-china-region/ instead of letting the application communicate directly with AWS IoT Core.

A similar approach is also adopted by the AWS Smart Product solution https://docs.aws.amazon.com/solutions/latest/smart-product-solution/architecture.html

Scaling authorization policies with AWS IoT Core

Relevant content