Module 4: Authorization

Lesson 1  of  7
Introduction to authorization
Authorization, also known as access management, determines what permissions or resource
access a user or service has. Authorization mechanisms rely on authentication as a prerequisite
and checks for access permissions only after you have successfully authenticated and are
connected to the environment. Authorization enables a system to enforce different levels of trust
(permissions) for authenticated users or systems, based on what those users or systems are
allowed to do.
Explore the concepts of authorization and access by moving through the informational tabs:

Purpose of authorization:
The purpose of authorization is to ensure that authenticated identities (such as a user or service) can
access only those resources to which their administrator has granted them permission.
Required access:
A user must be granted permissions to access resources in much the same way that an employee's badge
must be granted access to the parts of a physical building required by an employee to do their job. 
Reasonable need
An authenticated identity must have a reasonable need or business purpose to be given access; by default,
an authenticated identity has no access to any resources.
Examples:
Suppose that an employee is a medical doctor. The employee's badge would not have access to the
hospital data center because there is no business need for a doctor to be in the data center.  If an employee
is a switchboard operator, there would be no job-based reason for the operator to have access to the
cafeteria kitchen. The person must have a need to access an AWS resource.  This is the principle of least
privilege.

Principle of least privilege

The principle of least privilege is a design principle where users, services, applications
are granted only the necessary permissions to complete their required tasks. Limiting
resource access, limits the potential exposure if security is compromised. Decide the
extent of least privileges based on business requirements for that user/principal or
service.

When you create IAM policies, follow the standard security advice of granting least
privilege, or granting only the permissions required to perform a task. Determine exactly
what a user/role/device needs to do and then craft policies that allow them to perform
only those tasks.
Start with a minimum set of permissions and grant additional permissions only as
necessary. Doing so is more secure than starting with permissions that are too lenient and
then trying to tighten them later.

Next topic is on how to authorize and restrict access using IAM roles.

Lesson 2  of  7
IAM and IoT

AWS Identity and Access Management (IAM) is a web service that helps you securely control
access to AWS resources. You use IAM to control who is authenticated (signed in) and
authorized (has permissions) to use resources. 

An IAM user is an entity that you create within AWS to represent a person or application that
needs to interact with AWS resources. A user in AWS consists of a name and credentials and is
created to correspond to users in your organization.

IAM users, groups, and roles are the standard mechanisms for managing identity and
authentication in AWS. By contrast, AWS IoT policies are attached to X.509 certificates or
Amazon Cognito identities.

IAM users are not separate accounts; they are users contained and created within your
account. Each user has its own password to access the AWS Management Console. You
can create individual access keys so that each user can make programmatic requests to
work with resources in your account. 

User1-User4 have been added to a single AWS account using the AWS account credentials. Each user has its own credentials to
authenticate. When authenticated, they can have unique authorization access to resources.

Users assigned to groups

When you create an IAM user, you can grant it access to resources by adding it to a group that
has the appropriate permissions policies attached (recommended), or you can directly attach
policies to the user. An IAM group is a collection of IAM users. You can use groups to specify
permissions polices for a collection of users. These permissions policies determine what a user
can and cannot do and, by attaching the policy to a group, make these permissions easier to
manage. 

Policies are discussed in depth after we define IAM roles and how they are used in IoT
environments.
IAM roles 
An IAM role is an IAM identity that you can create in your account that has specific
permissions. An IAM role is similar to an IAM user in that it is an AWS identity with
permissions policies that determine what the identity can and cannot do; however, instead of
being uniquely associated with one person, a role is intended to be assumable by anyone who
needs it. Additionally, a role does not have standard long-term credentials, such as a password or
access keys associated with it. Instead, when you assume a role, it provides you with temporary
security credentials for your role session.

To explore the differences among IAM users, groups, and roles, select the appropriate flash card
below. 

IAM user
An IAM user has permanent long-term credentials and is used to directly
interact with AWS services.

IAM group
An IAM group is used to primarily manage the same set of permissions for a
set of IAM users.

IAM role
An IAM role is an entity with permissions to make AWS service requests.
IAM roles cannot make direct requests to AWS services; they are meant to be
assumed by authorized entities, such as IAM users, applications, or AWS
services, such as Amazon Elastic Compute Cloud (Amazon EC2). Use IAM
roles to delegate access within or between AWS accounts. 
 Things to remember:
 1
Role credentials are temporary. When you assume a role, it provides you with temporary security
credentials for your role session.
 2
Roles are assumed by any user or service who needs it. 
 3
Roles grant AWS IoT access to other services within AWS if access is required.
 4
A role can be used with an IoT rule to temporarily elevate permissions to complete a specific
action.
 5
Roles can be used for programmatic access.

Examples of programmatic access

Roles are also used for programmatic access. Programmatic access enables you to make requests
or take actions on AWS resources through an application, AWS CLI, or third-party tool. In
relation to IoT, a role is used to grant programmatic access to any service outside of the AWS
IoT Core. For example, if a device has a Publish topic that AWS IoT Core receives, you can
apply a rule with instructions to save that device data to an Amazon Simple Storage Service
(Amazon S3) bucket. In this case, programmatic access (permissions) would be required to
access and save the data to the S3 bucket. Roles grant access to the other AWS resources that
AWS IoT Core requires to, for example, save data, spawn a Lambda function, or save to an
Amazon DynamoDB table. 

Programmatic access uses an access key ID and a secret access key to sign authorization requests
to AWS. Apply best practices to protect access key IDs and secret access keys.
IAM Best Practices
To help secure your AWS resources, follow these recommendations.
IAM BEST PRACTICES

Creating a role
Before you create a rule, you must create an IAM role with a policy that allows access to the
required AWS resources. AWS IoT assumes this role when executing a rule.

Demo: Creating a role

In this demonstration, you will see the steps for creating an IoT role. Choose the image to
enlarge it.
START 
Step 1

Step 2
In the left navigation pane, select Roles, and then choose Create role.
Step 3:
On the Create role page, select Another AWS account.

Step 4: If you don't know your Account ID, you can retrieve it by selecting the account
name, and then choosing My Account.

Step5: When the Account Settings page opens, the Account ID is located at the top.
For security reasons, the account number has been covered with xxxxxxx. Copy your
number to the Clipboard and return to the Create role page.
Step6: For Account ID, enter your account number, and choose Next: Permissions.

Step 7
On the Attach permissions policies page, for Filter policies, enter IoT. 

In the results pane, select AWSIoTRuleActions. Select the down arrow to read what this role
does and the permissions it grants. This role allows access to all AWS services supported in
AWS IoT rule actions.
Step 8

For Role name, enter iot-demo-rule01

For Role description, enter a description for the role. 

To finish the role creation, choose Create role.

Summary
In this demonstration, we've walked through the process of creating a role that can be used for an
IoT rule.
FAQ
Click the button to read common IAM role questions.
IAM ROLES FAQ
Now that you are familiar with authorization identities, roles, and users, the next topic you will
explore is about AWS policies and how these policies allow or deny access to the AWS IoT
Core.

Lesson 3  of  7
Policies

Policies are JSON documents that define the permissions of an identity or resource. You attach a
policy to an identity or a resource, and the policy specifies what the identity can do. You manage
access in AWS by creating policies and attaching them to IAM identities or AWS resources. An
authenticated identity is used by devices, mobile apps, web applications, desktop applications, or
even a user running AWS IoT CLI commands. The identity can execute AWS IoT operations
only if it has a policy that grants it permission to perform the action. 

IAM policies and IoT policies are used with AWS IoT to control the operations an identity can
perform. The policy type used depends on the type of identity you are using to authenticate to
AWS IoT. 

Next, you'll explore IAM policies and IoT policies, and you'll review JSON documents that
define the permissions in these policies. Let's get started.

AWS IoT operations

AWS IoT operations are divided into two groups: control plane and data plane. To learn
more, select the appropriate tab.

Control plane API

Allows you to perform administrative tasks. 
For example:

 Creating or updating certificates

 Creating things and thing groups
 Creating IoT rules
 Logging
 OTA updates

Control Plane actions

AWS user or roles complete actions on the control plane through the AWS Management Console
or using the AWS CLI. Control plane actions define what functions an entity can and cannot
perform.

The users or roles will configure permissions or establish rules for your AWS IoT devices.

Data Plane API

Allows you to send data to and receive data from the AWS IoT Core.  
The AWS IoT data plane consists of operations that allow you to connect to the AWS IoT
message broker, send and receive MQTT messages, and get or update a device's shadow.

Data Plane actions

Devices or applications complete data plane actions as they connect and interact with
AWS IoT.  

Defined policies restrict these device actions.

IAM policies and the control plane

IAM policies are used to authorize control plane permissions and actions. IAM policies on the
control plane define what functions an entity can and cannot perform. There are a variety of IAM
policy types but this topic's focus is on identity-based policies. These policies control what
actions an entity (user or role) can perform, on which resources, and under what conditions.
Identity-based policies are categorized into managed and inline policies. There are two types of
managed policies: AWS managed and customer managed. 
To learn more about the policies and how to determine the best option for your environment,
select the appropriate tab.

.
AWS managed
–

An AWS managed policy is a standalone policy that is created and administered by AWS.
AWS managed policies are created with predefined permissions to address common use
cases. AWS managed policies make it easier for you to assign appropriate permissions to
users, groups, and roles than if you had to write the policies yourself.  If you are new to
using policies, we recommend that you start by using AWS managed policies. 
Customer managed
–

Customer managed policies are standalone identity–based policies that you create in
your AWS account. Customer managed policies provide more precise control over your
policies than AWS managed policies. You can then attach the policies to multiple
principal entities in your AWS account. When you attach a policy to a principal entity,
you give the entity the permissions that are defined in the policy. You can create and
edit an IAM policy in the visual editor or by creating the JSON policy document directly. 
Inline policy
–

Inline policies are created and attached directly to a single user, group, or role. You can
create inline policies when you first create a user, group, or role and only that user,
group, or role can use the policy attached to them. In most cases, we don't recommend
using inline policies.
Making the choice
–

The different types of policies are for different use cases. In most cases, we recommend
that you use managed policies instead of inline policies.

Managed policies provide the following features:

 Reusability
 Central change management
 Version and rollback
 Delegating permissions
 Automatic updates

Inline policies provide the following features:

 Maintains a strict one-to-one relationship between the policy and the
principal identity it is applied to.  
 The policy cannot be accidentally attached to the wrong identity. 
 When you delete the identity, the policy is deleted as well.
How do you determine whether to use an IoT policy, an IAM
policy, or both?

IoT policies
AWS IoT policies are attached to:

  X.509 certificates 

IAM policies
IAM policies are attached to:

 IAM user, group, or role

 Unauthenticated Amazon Cognito identity

Authenticated Amazon Cognito Identities

Both IoT and IAM policies are attached to:

 Amazon Cognito identities

Choosing
If you use the AWS IoT console or AWS IoT CLI to attach the policy to a
certificate or Amazon Cognito identity, use AWS IoT policy.

Use the IAM policy for all other situations.

AWS IoT policies

AWS IoT policies are JSON documents. They follow the same conventions as IAM policies.
AWS IoT also supports named policies so that multiple identities can reference the same policy
document. Named policies are also versioned so that they can be easily rolled back.

AWS IoT defines a set of policy actions that describe the operations and resources to which you
can grant or deny access. For example:

 iot:Connect represents permission to connect to the AWS IoT message

broker.
 iot:Subscribe represents permission to subscribe to an MQTT topic or topic
filter.
 iot:GetThingShadow represents permission to get a device's shadow.

What is JSON?  
JavaScript Object Notation (JSON) is a user-friendly, human-readable, lightweight data-
interchange format. It was created from a subset of JavaScript Programming Language, but
JSON is a text-based structured data based on key-value pairs. Even if you have no coding
background, it's easy for a person to roughly determine what's going on when reading JSON. It's
also easy for machines to parse and create because of its text-based format. 

Basic formatting:

 Key-value pairs have a colon between them. As in "key" : "value"

 Each key-value pair is separated by a comma. "key" : "value", "key" :
"value", "key": "value"

In the example below, take a moment to identify the "key" : "value" pairs.
"Version": "2019-09-09",
"Statement": [
{
"account_name" : "User1",
"account_id" : "12345",
"location" : "Seattle",
}
]
Answer: The key/value pairs are: account_name/User1, account_id/12345, and location/Seattle.

JSON policy documents

An AWS IoT policy is a JSON document. JSON policy documents are made up of elements.
Each statement contains required elements, such as Effect, Action, and Resource. In addition to
these required elements, there can be optional elements as well. The order of the elements doesn't
matter—for example, the Resource element can come before the Action element. 
  Version - The Version policy element is used within a policy and defines the version
of the policy language. It does not describe the change version or iteration of the
document.
 Statement - The main element for a policy. This element is required. The Statement
element contains an array of individual statements. Each individual statement is a
JSON block enclosed in braces { }.
 Effect - Use Allow or Deny to indicate whether the policy allows or denies access.
 Action - Includes a list of actions that the policy allows or denies
 Resource - Specifies a list of resources to which the actions apply. If no resource is
listed, then the resource to which the action applies is the resource to which the
policy is attached.

For devices registered as things in the AWS IoT registry, the above policy grants
permission to connect to AWS IoT with a client ID that matches the thing name and
restricts the device to publishing.

Wild cards and JSON documents

Wild cards are special characters that represent one or more other characters. Common wild
cards used in JSON documents are are asterisks "*" and question marks "?". 

The asterisk represents any or all characters or words. For example, a search for any .jpg on your
computer would read *.jpg and returns all files that have a .jpg extension.

The "?" replaces a single character. So a search for do? would return any three-letter word
beginning with the letters 'do': dog, dot, doc, doe, doh, don, and so on.

Wildcards are easy to use and have become popular, but you must use caution against potential
unauthorized user activity by an accidental or unfortunately misplaced asterisk.

 For example, an entry like the following will open your Amazon S3 bucket to any user on the
internet: 

Any action, on any item in the bucket, by any principal. Use wildcards carefully, and
make sure that you understand the ramifications.
AWS IoT policies
For more information about IoT polices and JSON formatting, choose Additional Info.
ADDITIONAL INFO
You have reviewed what policies do, the difference between IAM policies and IoT
policies, and the basics of policy formatting. Proceed to a demonstration in which we
create an IoT policy and attach the policy to a certificate. 

Lesson  4  of  7

Demo

Create and associate a policy with a certificate

In this demonstration, you will learn how to create and associate a policy. You learn how to
create a policy, review and edit the policy for security enhancements, and attach a policy to an
existing certificate.

Summary
In this demonstration, you learned how to create and associate a policy. You learned how to
create a policy, review and edit the policy for security enhancements, and attach a policy to an
existing certificate.
Lesson 5  of  7
Best practices
 1
Use the principle of least privilege when assigning permissions.
 2
Ensure that a thing publishes and subscribes only to required topics and not to every available
topic.
 3
Grant AWS IoT Core services only those permissions to perform tasks required for their unique
situation.
Lesson 6 of 7
Knowledge check
Answer the following question to check what you've learned.
START QUIZ