IAM stands for Identity Access Management.
IAM allows you to manage users and their level of access to the aws console.
It is used to set users, permissions and roles. It allows you to grant access to the different parts of the aws platform.
AWS Identity and Access Management is a web service that enables Amazon Web Services (AWS) customers to manage users and user permissions in AWS.
With IAM, Organizations can centrally manage users, security credentials such as access keys, and permissions that control which AWS resources users can access.
Without IAM, Organizations with multiple users must either create multiple user accounts, each with its own billing and subscriptions to AWS products or share an account with a single security credential. Without IAM, you also don't have control about the tasks that the users can do.
IAM enables the organization to create multiple users, each with its own security credentials, controlled and billed to a single aws account. IAM allows the user to do only what they need to do as a part of the user's job.
Centralised control of your AWS account: You can control creation, rotation, and cancellation of each user's security credentials. You can also control what data in the aws system users can access and how they can access.
Shared Access to your AWS account: Users can share the resources for the collaborative projects.
Granular permissions: It is used to set a permission that user can use a particular service but not other services.
Identity Federation: An Identity Federation means that we can use Facebook, Active Directory, LinkedIn, etc with IAM. Users can log in to the AWS Console with same username and password as we log in with the Active Directory, Facebook, etc.
Multifactor Authentication: An AWS provides multifactor authentication as we need to enter the username, password, and security check code to log in to the AWS Management Console.
Permissions based on Organizational groups: Users can be restricted to the AWS access based on their job duties, for example, admin, developer, etc.
Networking controls: IAM also ensures that the users can access the AWS resources within the organization's corporate network.
Provide temporary access for users/devices and services where necessary: If you are using a mobile app and storing the data in AWS account, you can do this only when you are using temporary access.
Integrates with many different aws services: IAM is integrated with many different aws services.
Supports PCI DSS Compliance: PCI DSS (Payment Card Industry Data Security Standard) is a compliance framework. If you are taking credit card information, then you need to pay for compliance with the framework.
Eventually Consistent: IAM service is eventually consistent as it achieves high availability by replicating the data across multiple servers within the Amazon's data center around the world.
Free to use: AWS IAM is a feature of AWS account which is offered at no additional charge. You will be charged only when you access other AWS services by using IAM user.
SAML stands for Security Assertion Markup language.
Generally, users need to enter a username and password to login in any application.
SAML is a technique of achieving Single Sign-On (SSO).
Security Assertion Markup Language (SAML) is an Xml-based framework that allows the identity providers to provide the authorization credentials to the service provider.
With SAML, you need to enter one security attribute to log in to the application
SAML is a link between the authentication of the user's identity and authorization to use a service.
SAML provides a service known as Single Sign-On means that users have to log in once and can use the same credentials to log in to another service provider.
With SAML, both the service provider and identity provider exist separately, but centralizes the user management and provides access to the SaaS solutions.
SAML authentication is mainly used for verifying the user's credentials from the identity provider.
SAML SSO (SINGLE SIGN-ON): SAML provides security by eliminating passwords for an app and replacing them with the security tokens. Since we do not require any passwords for SAML logins, there is no risk of credentials to be stolen by unauthorized users. It provides faster, easier and trusted access to cloud applications.
Open Standard SINGLE SIGN-ON: SAML implementations confirms to the open standard. Therefore, it is not restricted to a single identity provider. This open standard allows you to choose the SAML provider.
Strong Security: SAML uses federated identities and secure tokens to make SAML one of the best secure forms for web-based authentication.
Improved online experience for end users: SAML provides SINGLE SIGN-ON (SSO) to authenticate at an identity provider, and the identity provider sends the authentication to the service provider without additional credentials.
Reduced administrative costs for service providers: Using single authentication multiple times for multiple services can reduce the administrative costs for maintaining the account information.
Risk transference: SAML has put the responsibility of handling the identities to the identity provider.
SAML provider is an entity within a system that helps the user to access the services that he or she wants.
There are two types of SAML providers:
Service provider
Identity provider
It is an entity within a system that provides the services to the users for which they are authenticated.
Service provider requires the authentication from the identity provider that grants the access to the user.
Salesforce and other CRM are the common service providers.
An identity provider is an entity within a system that sends the authentication to the service provider is about who they are along with the user access rights.
It maintains a directory of the user and provides an authentication mechanism.
Microsoft Active Directory and Azure are the common identity providers.
A SAML Assertion is an XML document that the identity provider sends to the service provider containing user authorization.
SAML Assertion is of three types:
Authentication
It proves the identification of the user
It provides the time at which the user logged in.
It also determines which method of authentication has been used.
Attribute
An attribute assertion is used to pass the SAML attributes to the service provider where attribute contains a piece of data about the user authentication.
Authorization decision
An authorization decision determines whether the user is authorized to use the service or identity provider denied the request due to the password failure.
If a user tries to access the resource on the server, the service provider checks whether the user is authenticated within the system or not. If you are, you skip to step 7, and if you are not, the service provider starts the authentication process.
The service provider determines the appropriate identity provider for you and redirects the request to the identity provider.
An authentication request has been sent to the SSO (SINGLE SIGN-ON) service, and SSO service identifies you.
The SSO service returns with an XHTML document, which contains authentic information required by the service provider in a SAMLResponse parameter.
The SAMLResponse parameter is passed to the Assertion Consumer Service (ACS) at the service provider.
The service provider processes the request and creates a security context; you automatically logged in.
After login, you can request for a resource that you want.
Finally, the resource is returned to you.
IAM identities are created to provide authentication for people and processes in your aws account.
IAM identities are categorized as given below:
When you first create an AWS account, you create an account as a root user identity which is used to sign in to AWS.
You can sign to the AWS Management Console by entering your email address and password. The combination of email address and password is known as root user credentials.
When you sign in to AWS account as a root user, you have unrestricted access to all the resources in AWS account.
The Root user can also access the billing information as well as can change the password also.
A role is a set of permissions that grant access to actions and resources in AWS. These permissions are attached to the role, not to an IAM User or a group.
An IAM User can use a role in the same AWS account or a different account.
An IAM User is similar to an IAM User; role is also an AWS identity with permission policies that determine what the identity can and cannot do in AWS.
A role is not uniquely associated with a single person; it can be used by anyone who needs it.
A role does not have long term security credential, i.e., password or security key. Instead, if the user uses a role, temporarily security credentials are created and provided to the user.
You can use the roles to delegate access to users, applications or services that generally do not have access to your AWS resources.
Sometimes you want to grant the users to access the AWS resources in your AWS account.
Sometimes you want to grant the users to access the AWS resources in another AWS account.
It also allows the mobile app to access the AWS resources, but not want to store the keys in the app.
It can be used to grant access to the AWS resources which have identities outside of AWS.
It can also be used to grant access to the AWS resources to the third party so that they can perform an audit on AWS resources.
Delegation: Delegation is a process of granting the permissions to the user to allow the access to the AWS resources that you control. Delegation sets up the trust between a trusted account (an account that owns the resource) and a trusting account (an account that contains the users that need to access the resources). The trusting and trusted account can be of three types:
Same account
Two different accounts under the same organization control
Two different accounts owned by different organizations.
To delegate permission to access the resources, an IAM role is to be created in the trusting account that has the two policies attached.
Permission Policy: It grants the user with a role the needed permissions to carry out the intended tasks.
Trust Policy: It specifies which trusted account members can use the role.
Federation: Federation is a process of creating the trust relationship between the external service provider and AWS. For example, Facebook allows the user to login to different websites by using their facebook accounts.
Trust policy: A document was written in JSON format to define who is allowed to use the role. This document is written based on the rules of the IAM Policy Language.
Permissions policy: A document written in JSON format to define the actions and resources that the role can use. This document is based on the rules of the IAM Policy Language.
Permissions boundary: It is an advanced feature of AWS in which you can limit the maximum permissions that the role can have. The permission boundaries can be applied to IAM User or IAM role but cannot be applied to the service-linked role.
Principal: A principal can be AWS root account user, an IAM User, or a role. The permissions that can be granted in one of the two ways:
Attach a permission policy to a role.
The services that support resource-based policies, you can identify the principal in the principal element of policy attached to the resource.
Cross-account access: Roles vs Resource-Based Policies: It allows you to grant access to the resources in one account to the trusted principal in another account is known as cross-account access. Some services allow you to attach the policy directly, known as Resource-Based policy. The services that support Resource-Based Policy are Amazon S3 buckets, Amazon SNS, Amazon SQS Queues.
There are two ways to use the roles:
IAM Console: When IAM Users working in the IAM Console and want to use the role, then they access the permissions of the role temporarily. An IAM Users give up their original permissions and take the permissions of the role. When IAM User exits the role, their original permissions are restored.
Programmatic Access: An AWS service such as Amazon EC2 instance can use role by requesting temporary security credentials using the programmatic requests to AWS.
An IAM Role can be used in the following ways:
IAM User: IAM Roles are used to grant the permissions to your IAM Users to access AWS resources within your own or different account. An IAM User can use the permissions attached to the role using the IAM Console. A Role also prevents the accidental access to the sensitive AWS resources.
Applications and Services: You can grant the access of permissions attached with a role to applications and services by calling the AssumeRole API function. The AssumeRole function returns a temporary security credentials associated with a role. An application and services can only take those actions which are permitted by the role. An application cannot exit the role in the way the IAM User in Console does, rather it stops using with the temporary credentials and resumes its original credentials.
Federated Users: Federated Users can sign in using the temporary credentials provided by an identity provider. AWS provides an IDP (identity provider) and temporary credentials associated with the role to the user. The credentials grant the access of permissions to the user.
Following are the cases of Roles:
Switch to a role as an IAM User in one AWS account to access resources in another account that you own.
You can grant the permission to your IAM Users to switch roles within your AWS account or different account. For example, you have Amazon EC2 instances which are very critical to your organization. Instead of directly granting permission to users to terminate the instances, you can create a role with the privileges that allows the administrators to switch to the role when they need to terminate the instance.
You have to grant users permission to assume the role explicitly.
Multi-factor authentication role can be added to the role so that only users who sign in with the MFA can use the role.
Roles prevent accidental changes to the sensitive resource, especially if you combine them with the auditing so that the roles can only be used when needed.
An IAM User in one account can switch to the role in a same or different account. With roles, a user can access the resources permitted by the role. When user switch to the role, then their original permissions are taken away. If a user exits the role, their original permissions are restored.
Providing access to an AWS service
AWS services use roles to access a AWS resources.
Each service is different in how it uses roles and how the roles are assigned to the service.
Suppose an AWS service such as Amazon EC2 instance that runs your application, wants to make request to the AWS resources such as Amazon S3 bucket, the service must have security credentials to access the resources. If you embed security credentials directly into the instance, then distributing the credentials to the multiple instances create a security risk. To overcome such problems, you can create a role which is assigned to the Amazon EC2 instance that grants the permission to access the resources.
Providing access to externally authenticated users. Sometimes users have identities outside of AWS such as in your corporate directory. If such users want to work with the AWS resources, then they should know the security credentials. In such situations, we can use a role to specify the permissions for a third-party identity provider (IDP).
SAML -based federation SAML 2.0 (Security Assertion Markup Language 2.0) is an open framework that many identity providers use. SAML provides the user with the federated single-sign-on to the AWS Management Console, so that user can log in to the AWS Management Console. How SAML-based federation works
Web-identity federation Suppose you are creating a mobile app that accesses AWS resources such as a game that run on a mobile device, but the information is stored using Amazon S3 and DynamoDB. When you create such an app, you need to make requests to the AWS services that must be signed with an AWS access key. However, it is recommended not to use long-term AWS credentials, not even in an encrypted form. An Application must request for the temporary security credentials which are dynamically created when needed by using web-identity federation. These temporary security credentials will map to a role that has the permissions needed for the app to perform a task. With web-identity federation, users do not require any custom sign-in code or user identities. A User can log in using the external identity provider such as login with Amazon, Facebook, Google or another OpenID. After login, the user gets the authentication token, and they exchange the authentication token for receiving the temporary security credentials.
Providing access to third parties When third parties want to access the AWS resources, then you can use roles to delegate access to them. IAM roles grant these third parties to access the AWS resources without sharing any security credentials. Third parties provide the following information to create a role:
The third party provides the account ID that contains the IAM Users to use your role. You need to specify AWS account ID as the principal when you define the trust policy for the role.
The external ID of the third party is used to associate with the role. You specify the external ID to define the trust policy of the role.
The permissions are used by the third party to access the AWS resources. The permissions are associated with the role made when you define the trust policy. The policy defines the actions what they can take and what resources they can use.
Creating a Role for a service using the AWS Management Console.
In the navigation pane of the console, click Roles and then click on "Create Role". The screen appears shown below on clicking Create Role button.
Choose the service that you want to use with the role.
Select the managed policy that attaches the permissions to the service.
In a role name box, enter the role name that describes the role of the service, and then click on "Create role".
Creating a Role for a service using the CLI (Command Line Interface)
Creating a role using the console, many of the steps are already done for you, but with the CLI you explicitly perform each step yourself. You must create a policy, and assign a permission policy to the role. To create a role for an AWS service using the AWS CLI, use the following commands:
Create a role: aws iam create-role
Attach a permission policy to the role: aws iam put-role-policy
If you are using a role with instance such as Amazon EC2 instance, then you need to create an instance profile to store a role. An instance profile is a container of role, but instance profile can contain only one role. If you create the role by using AWS Management Console, then instance profile is already created for you. If you create the profile using CLI, you must explicitly specify each step yourself. To create an instance profile using CLI, use the following commands:
Create an instance profile: aws iam create-instance-profile
Add a role to instance profile: aws iam add-role-to-instance-profile
Creating a Role for an IAM User using AWS Management Console
In the navigation pane of the console, click Roles and then click on "Create Role". The screen appears shown below on clicking Create Role button.
Specify the account ID that you want to grant the access to the resources, and then click on Next Permissions button.
If you selected the option "Require external ID" means that it allows the users from the third party to access the resources. You need to enter the external ID provided by the administrator of the third party. This condition is automatically added to the trust policy that allows the user to assume the role.
If you selected the option "Require MFA" is used to restrict the role to the users who provide Multi-factor authentication.
Select a policy that you want to attach with the role. A policy contains the permissions that specify the actions that they can take and resources that they can access.
In a role name box, enter the role name and the role description.
Click on Create role to complete the creation of the role.
Creating a Role for an IAM User using CLI (Command Line Interface)
Backward Skip 10sPlay VideoForward Skip 10s
When you use the console to create a role, many of the steps are already done for you. In the case of CLI, you must specify each step explicitly.
To create a role for cross-account access using CLI, use the following commands:
Create a role: aws iam create-role
Attach a permission policy to the role: aws iam put-role-policy
Identity Federation allows you to access AWS resources for users who can sign in using third-party identity provider. To configure Identity Federation, you must configure the identity provider and then create an IAM Role that determines the permissions which federated users can have.
Web Identity Federation: Web Identity Federation provides access to the AWS resources which have signed in with the login with facebook, Google, Amazon or another Open ID standard. To configure with the Web Identity Federation, you must first create and configure the identity provider and then create the IAM Role that determines the permissions that federated users will have.
Security Assertion Markup Language (SAML) 2.0 Federation: SAML-Based Federation provides access to the AWS resources in an organization that uses SAML. To configure SAML 2.0 Based Federation, you must first create and configure the identity provider and then create the IAM Role that determines the permissions the federated users from the organization will have.
Creating a Role for a web identity using AWS Management Console
Open the IAM Console at https://console.aws.amazon.com/iam/
In the navigation pane, click Roles and then click on Create role.
After clicking on the create role, select the type of trusted entity, i.e., web identity
Specify the client ID that identifies your application.
If you are creating a role for Amazon Cognity, specify the ID of the identity pool when you have created your Amazon Cognito applications into the identity Pool ID box.
If you are creating a role for a single web identity provider, specify the ID that the provider provides when you have registered your application with the identity provider.
(Optional) Click Add Conditions to add the additional conditions that must be met before users of your application can use the permissions granted by the role.
Now, attach the permission policies to the role and then click Next: Tags.
In a role name box, specify the role name and role description
Click Create role to complete the process of creation of role.
Creating a Role for SAML Based 2.0 Federation using AWS Management Console
Open the IAM Console at https://console.aws.amazon.com/iam/
In the navigation pane of the console, Click Roles and then click on Create role
Click on Role for Identity Provider Access.
Select the type of the role that you want to create for Grant Web Single Sign-On (SSO) or Grant API access.
Select the SAML Provider for which you want to create the role.
If you are creating a role for API access, select the attribute from the attribute list. Then in the value box, enter the value that you want to include in the role. It restricts the access to the role to the users from the identity providers whose SAML authentication response includes the attributes you select.
If you want to add more attribute related conditions, click on Add Conditions.
Attach the permission policies to the role.
Click Create role to complete the process of creation of role.
Creating a role for Federated Users using AWS CLI
To create a role for federated users using AWS CLI, use the following commands:
Create a role: aws iam create-role
