,
resource == ?resource
)
when { context.desiredTemperature >= 72 && context.desiredTemperature = 840 && context.time < 1020 }; The policy templates accept the user and resource. The next step is to create a template-linked policy for Jane to set and get thermostat readings based on the Guest user template that you created earlier. For simplicity, you will manually create this policy using the Verified Permissions console. In production, application policies can be dynamically created using the Verified Permissions API. To create a template-linked policy for a guest user In the Verified Permissions console, on the left pane, select Policies, then choose Create policy and select Create template-linked policy from the drop-down menu.  Figure 12: Create new template-linked policy Select the Guest user template and choose next.  Figure 13: Select Guest user template Under parameter selection: For Principal enter AwsIotAvpWebApp::User::”jane_doe”. For Resource enter AwsIotAvpWebApp::Device::”Thermostat1″. Choose Create template-linked policy.  Figure 14: Create guest user template-linked policy Note that with this policy in place, jane_doe can only set the temperature of the device Thermostat1 to between 72°F and 78°F. To create a template-linked policy for the power company user Based on the template that was set up for power company, you now need an actual policy for it. In the Verified Permissions console, go to the left pane and select Policies, then choose Create policy and select Create template-linked policy from the drop-down menu. Select the Power company user template and choose next. Under Parameter selection, for Principal enter AwsIotAvpWebApp::User::”powercompany”, and for Resource enter AwsIotAvpWebApp::Device::”Thermostat1″, and choose Create template-linked policy. Now that you have a set of policies in a policy store, you need to update the backend codebase to include this information and then deploy the web application using Amplify. The policy statements in this post intentionally use human-readable values such as jane_doe and powercompany for the principal entity. This is useful when discussing general concepts but in production systems, customers should use unique and immutable values for entities. See Get the best out of Amazon Verified Permissions by using fine-grained authorization methods for more information. Deploy the solution code from GitHub Go to the GitHub repository to set up the Amplify web application. The repository Readme file provides detailed instructions on how to set up the web application. You will need your Verified Permissions policy store ID to deploy the application. For convenience, we’ve provided an onboarding script—deploy.sh—which you can use to deploy the application. To deploy the application Close the repository. git clone https://github.com/aws-samples/amazon-verified-permissions-iot- amplify-smart-home-application.git Deploy the application. ./deploy.sh After the web dashboard has been deployed, you’ll create an IoT device using AWS IoT Core. Create an IoT device and connect it to AWS IoT Core With the users, policies, and templates, and the Amplify smart home application in place, you can now create a device and connect it to AWS IoT Core to complete the solution. To create Thermostat1” device and connect it to AWS IoT Core From the left pane in the AWS IoT console, select Connect one device.  Figure 15: Connect device using AWS IoT console Review how IoT Thing works and then choose Next.  Figure 16: Review how IoT Thing works before proceeding Choose Create a new thing and enter Thermostat1 as the Thing name and choose next.&bsp; Figure 17: Create the new IoT thing Select Linux/macOS as the Device platform operating system and Python as the AWS IoT Core Device SDK and choose next.  Figure 18: Choose the platform and SDK for the device Choose Download connection kit and choose next.  Figure 19: Download the connection kit to use for creating the Thermostat1 device Review the three steps to display messages from your IoT device. You will use them to verify the thermostat1 IoT device connectivity to the AWS IoT Core platform. They are: Step 1: Add execution permissions Step 2: Run the start script Step 3: Return to the AWS IoT Console to view the device’s message  Figure 20: How to display messages from an IoT device Solution validation With all of the pieces in place, you can now test the solution. Primary owner signs in to the web application to set Thermostat1 temperature to 82°F Figure 21: Thermostat1 temperature update by John Sign in to the Amplify web application as John. You should be able to view the Thermostat1 controller on the dashboard. Set the temperature to 82°F. The Lambda function processes the request and performs an API call to Verified Permissions to determine whether to ALLOW or DENY the action based on the policies. Verified Permissions sends back an ALLOW, as the policy that was previously set up allows unrestricted access for primary owners. Upon receiving the response from Verified Permissions, the Lambda function sends ALLOW permission back to the web application and an API call to the AWS IoT Device Shadow service to update the device (Thermostat1) temperature to 82°F.  Figure 22: Policy evaluation decision is ALLOW when a primary owner calls SetTemperature Guest user signs in to the web application to set Thermostat1 temperature to 80°F Figure 23: Thermostat1 temperature update by Jane If you sign in as Jane to the Amplify web application, you can view the Thermostat1 controller on the dashboard. Set the temperature to 80°F. The Lambda function validates the actions by sending an API call to Verified Permissions to determine whether to ALLOW or DENY the action based on the established policies. Verified Permissions sends back a DENY, as the policy only permits temperature adjustments between 72°F and 78°F. Upon receiving the response from Verified Permissions, the Lambda function sends DENY permissions back to the web application and an unauthorized response is returned.  Figure 24: Guest user jane_doe receives a DENY when calling SetTemperature for a desired temperature of 80°F If you repeat the process (still as Jane) but set Thermostat1 to 75°F, the policy will cause the request to be allowed.  Figure 25: Guest user jane_doe receives an ALLOW when calling SetTemperature for a desired temperature of 75°F Similarly, jane_doe is allowed run GetTemperature on the device Thermostat1. When the temperature is set to 74°F, the device shadow is updated. The IoT device being simulated by your AWS Cloud9 instance reads desired the temperature field and sets the reported value to 74. Now, when jane_doe runs GetTemperature, the value of the device is reported as 74 as shown in Figure 26. We encourage you to try different restrictions in the World Settings (outside temperature and time) by adding restrictions to the static policy that allows GetTemperature for guest user.  Figure 26: Guest user jane_doe receives an ALLOW when calling GetTemperature for the reported temperature Power company signs in to the web application to set Thermostat1 to 78°F at 3.30 PM Figure 27: Thermostat1 temperature set to 78°F by powercompany user at a specified time Sign in as the powercompany user to the Amplify web application using an API. You can view the Thermostat1 controller on the dashboard. To test this scenario, set the current time to 3:30 PM, and try to set the temperature to 78°F. The Lambda function validates the actions by sending an API call to Verified Permissions to determine whether to ALLOW or DENY the action based on pre-established policies. Verified Permissions returns ALLOW permission, because the policy for powercompany permits device temperature changes between 2:00 PM and 5:00 PM. Upon receiving the response from Verified Permissions, the Lambda function sends ALLOW permission back to the web application and an API call to the AWS IoT Device Shadow service to update the Thermostat1 temperature to 78°F.  Figure 28: powercompany receives an ALLOW when SetTemperature is called with the desired temperature of 78°F Note: As an optional exercise, we also made jane_doe a device owner for device Thermostat2. This can be observed in the users.json file in the Github repository. We encourage you to create your own policies and restrict functions for Thermostat2 after going through this post. You will need to create separate Verified Permissions policies and update the Lambda functions to interact with these policies. We encourage you to create policies for guests and the power company and restrict permissions based on the following criteria: Verify Jane Doe can perform GetTemperature and SetTemperature actions on Thermostat2. John Doe should not be able to set the temperature on device Thermostat2 outside of the time range of 4:00 PM and 6:00 PM and outside of the temperature range of 68°F and 72°F. Power Company can only perform the GetTemperature operation, but there are no restrictions on time and outside temperature. To help you verify the solution, we’ve provided the correct policies under the challenge directory in the GitHub repository. Clean up Deploying the Thermostat application in your AWS account will incur costs. To avoid ongoing charges, when you’re done examining the solution, delete the resources that were created. This includes the Amplify hosted web application, API Gateway resource, AWS Cloud 9 environment, the Lambda function, DynamoDB table, Cognito user pool, AWS IoT Core resources, and Verified Permissions policy store. Amplify resources can be deleted by going to the AWS CloudFormation console and deleting the stacks that were used to provision various services. Conclusion In this post, you learned about creating and managing fine-grained permissions using Verified Permissions for different user personas for your smart thermostat IoT device. With Verified Permissions, you can strengthen your security posture and build smart applications aligned with Zero Trust principles for real-time authorization decisions. To learn more, we recommend: Getting started with Amazon Verified Permissions Best practices for defining authorization model with Amazon Verified Permissions Working with AWS IoT in AWS Cloud9 IDE  If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support. Rajat Mathur Rajat is a Principal Solutions Architect at Amazon Web Services. Rajat is a passionate technologist who enjoys building innovative solutions for AWS customers. His core areas of focus are IoT, Networking, and Serverless computing. In his spare time, Rajat enjoys long drives, traveling, and spending time with family. Pronoy Chopra Pronoy is a Senior Solutions Architect with the Startups Generative AI team at AWS. He specializes in architecting and developing IoT and Machine Learning solutions. He has co-founded two startups and enjoys being hands-on with projects in the IoT, AI/ML and Serverless domain. His work in Magnetoencephalography has been cited many times in the effort to build better brain-compute interfaces. Syed Sanoor Syed serves as a Solutions Architect, assisting customers in the enterprise sector. With a foundation in software engineering, he takes pleasure in crafting solutions tailored to client needs. His expertise predominantly lies in C# and IoT. During his leisure time, Syed enjoys piloting drones and playing cricket."]