Secure identity and access management is of paramount importance to every public cloud service and resource provider. Amazon Web Services (AWS) is one such public cloud providers that takes identity and access management very seriously. In this article, I will explain fundamental concepts that cloud architects and engineers should understand when setting out to build systems and services on AWS .

First let us differentiate between authentication and authorization.

Authentication: the process of verifying or confirming who an entity claims to be. Entities may need to supply usernames, passwords, API keys, tokens, etc in order to be authenticated.

Authorization: the process of assigning permissions to entities to access specific resources and services based on their identities. Most of the concepts discussed in this article will deal with authorizations to access AWS resources.

The email address and password that is used to create an AWS account is referred to as the Root User Identity or Root User Credentials. This is a superuser credentials that gives unrestricted access and control of all resources within an account.

IAM user: Since the root user credentials are recommended for only superuser and admin tasks, you need to create IAM user credentials for each user that will need to access some resources within the AWS account. An IAM user can have a password in order to log into the AWS management console (https://console.aws.amazon.com/) and an access key to programatically access resources.

Federated User: If you manage identities using AWS Cognito or other identity providers outside AWS (examples: Google, Facebook, Amazon, Apple, etc), then the authenticated users returned by the identity providers are referred to as federated users. 

Group: As the name suggests a group is just a collection of IAM users with shared permissions. For example, groups may be used to attach shared permissions to users who may belong to the list of 'authors' or 'admins' in a collaborative platform.

Role: An IAM role is an identity that can be taken on temporarily by a user or service. So a role is not tied to single user but can be assumed or taken on by different users or services. The essence of roles is to delegate access to users and services that do not normally have a fixed associated identity.

Principal: Refers to a user or service that uses or assumes an IAM identity (IAM user or role). 

Policy: A policy defines the permissions that an IAM identity has. Additionally, a policy may be used to define the actions that a resource should permit from an identity. The two most commonly used policies are identity-based and resource-based policies. As the names suggest, an identity-based policy defines the permissions of a user/group or a role while a resource-based identity defines the principals (identities) to which a resource should grant specific actions.

Trust policy: a type of resource-based policy that defines the conditions that must be met before a principal is allowed to assume a role.

Permissions boundary policy: A permissions boundary policy is only used to set the possible list of permissions/actions an IAM identity can have. It does not directly attach a permission to an entity, it only limits the possible permissions an identity can be granted.

Lastly, one has to understand the principle of least privilege which advocates that a principal must only be given the minimum set of permissions to required to complete its tasks. And as AWS strongly advocates for this principle of least privilege, you must bear it in mind when creating and attaching policies to identities in AWS.

If you have any question or comment, do not hesitate to put it forward below.