Authentication Methods

What Is Authentication In AWS?

Authentication is the process by which users sign into AWS with their identity. To submit a request to AWS as a principle, users should be authorized (logged in to Amazon) to use an entity (root user, IAM user, or IAM role). Long-term permissions, like a password and user name or a collection of access keys, can be assigned to an IAM user. Users are issued provisional security credentials whenever they take on such an IAM position.

To log in as a client via the AWS Management Consoles, log in along with the password and username. Users should supply the access keys and secret keys, or provisional credentials, to register using the AWS CLI or AWS APIs. Aws offers SDK and CLI tools for signing the request's cryptographic keys utilizing their credential.

Users should sign the requests manually when they do not utilize the AWS tool. Users may be needed to supply additional security information regardless of the authentication mechanism they select. AWS Authentication Methods, for example, suggests using MFA to strengthen the protection of the accounts.

Different Types Of Entities/Roles Provided By AWS For Authentication

Root Users Of The AWS Accounts
Whenever users register any AWS account, users begin with a single sign-in id which has full access to all of the account's AWS resources and services. Such identity is referred to as the AWS accounts root users, and it may be accessible by logging in using the passwords and email addresses used to set up your account.

IAM Users
The entity having specified rights in the AWS accounts is known as an IAM user. MediaConvert support the inbound API requests authentication standard known as Signatures Versions 4.

IAM Role
Users may establish an IAM identity with particular rights called an IAM role in the accounts. Similarly to the IAM users, an IAM role is the AWS identity which has a permission policy that limits what it's allowed to perform in AWS.

AWS Account Root User

Whenever users open an AWS account, they start with an SSO identity which has full access to all the account's resources and AWS Authentication Methods service. Using the passwords and email addresses used to establish the accounts, users may log in as the AWS accounts root users to obtain this identity.

It is highly advised against using root users for routine operations. Employ the root user credential responsibly and solely for things that just the root users are capable of performing.

IAM User

The entities in the AWS accounts known as IAM user has particular rights for just a single individual or app. Long-term credentials for such an IAM user may include a user name, passwords, or collection of the access key. Users should sign in using the password and username to verify themselves as just an IAM user through the AWS Management Console. Users should enter the IAM user access key IDs and secret keys to be authorized through the AWS CLI or AWS API.

• Ensure that examine and store the pair of keys whenever users produce access keys for the IAM users. The secret access keys cannot be retrieved as in the hereafter. Rather, users need to create a fresh set of access keys.
• The set of IAM users is known as an IAM group. To set permission for several users at once, utilize group. For big user populations, a group makes managing permission simpler. For instance, one might create a group called AdminIAM and provide it the ability to manage IAM resources.
• Users and roles are distinct. A role is meant to be assumed by anybody who requires it, whereas a user is only ever linked to one person or program. Roles offer temporary credentials whereas users get an everlasting credential.

IAM Role

In the AWS account, there is a thing called an IAM role which has particular rights. It is comparable to IAM users but not connected to a specific individual. With AWS Management Console, users may effectively take on such an IAM position by changing roles. Users may take on a role by utilizing a custom URL, the AWS CLI or AWS API actions, or both.

The following scenarios call for the usage of the IAM role using provisional credentials:

IAM User Permissions Temporarily
To momentarily take on various rights for a particular job, IAM users might acquire an IAM role.

Access By Federated Users
Users must construct a role and specify permission again for roles to grant permission to federated identities. The federated identities that successfully authenticate are assigned the roles and given all rights which are specified by the role.  Users may set up a permissions group if they utilize IAM Identity Center. IAM Identity Centers associate the permissions group with an IAM role to limit whatever the identities may access after authenticating in AWS Authentication Methods. 

Access Between Accounts
A trusted principal in another account can access the resource in their accounts by using an IAM role. The main method for granting cross-account accessibility is through the role. However, users may directly attach the policies to the resources with some Aws resources

Accessibility To AWS Services
The services can operate on our behalf by assuming an IAM position known as just a service role. From within IAM, the administrators may build, amend, and remove the service roles.

Utilizing Applications On AWS EC2
The IAM role can handle provisional login information for EC2 instance-running apps that utilize the AWS CLI or AWS API. Instead of keeping the access key inside the EC2 instances, do this. You must build the instance profiles which is associated with an instance to allocate an AWS role to it and to make it accessible to each of the apps running on it. Programs operating on an EC2 instance can access temporarily resources thanks to instance profiles, which also include the role in AWS Authentication Methods.

Principal Role
You can allow cross-account access to your resources for various AWS services. Instead of employing a role as a proxy, you attach a policy directly to the resource you wish to share. If this policy type is supported by the service, the resource you want to share must also support resource-based policies. Unlike a user-based policy, a resource-based policy states who (in the form of a list of AWS account ID numbers) can use that resource. Resource-based policies are not supported by MediaConvert.

A resource-based policy with cross-account access offers several advantages over a role. With a resource that is accessible through a resource-based policy, the principal (person or application) still works in the trusted account and does not have to give up their user permissions in place of the role permissions. In other words, the principal has simultaneous access to resources in both the trusted and trusting accounts. This is helpful for things like copying data from one account to another.

Federated User Access

Users must construct a role and specify permission for the roles to grant permission to a federation identity. Federated identities that successfully authenticate are assigned the role and given the rights which are specified by the roles.  Users may set up permissions sets if users utilize IAM Identity Center. IAM Identity Centers associate the permissions sets with an IAM role to limit whatever user identity may access upon authenticating.

Temporary User Permissions

When temporarily taking on various rights for just a particular job, IAM users might assume a specific role in AWS Authentication Methods.

Cross-Account Access

The trustworthy principal in another account can access the resource in the account by using IAM roles. The main method for granting cross-account accessibility is through the role. But, users may directly link a policy to the resources with some Aws resources. It is not supported by MediaConvert for certain asset-based policies.

AWS Service Access

The services can act on their behalf by assuming an IAM position known as a service role. From inside IAM, administrators may build, modify, and remove service roles.

Applications Running On Amazon EC2

The IAM role can be used to handle provisional login information for EC2 instance-running apps that use the AWS CLI or AWS API. Instead of keeping the key inside the EC2 instance, do this. Users must build an instance profile that is associated with the instance to give an AWS role to it and provide access to each of the apps running upon that. Applications operating on an EC2 instance can obtain provisional permissions thanks to instance profiles, which also include the roles in AWS Authentication Methods.

Controlling Access Using Policies

• By establishing policies and tying these to IAM credentials and AWS services, users may control access to AWS. For AWS, a policy is indeed an object such, if linked to an entity or resources, determines the rights for that recourses or entity.
• Whenever a principal, like a customer, submits a request, AWS assesses those rules. Whether such a request is approved or rejected depends on the permission inside the policy. The majority of policies are kept in AWS as JSON files.
• IAM administrators may define who might have access to AWS resources and also what action users are permitted to do on these resources using policy. Each user or role in the IAM system is created with no privileges. In those other words, users cannot alter their passwords or do anything else by default.
• The admin should associate a permission policy with a user before authorizing them to do a task. Alternatively, the admin can include the user in a group that already has the required rights. Every user who is a member of a group is given the rights that an administrator grants to that group.
• Regardless of the technique users choose to carry out the process, IAM policies set permission for just action. Consider the case when your policy permits the IAM GetUser actions. The AWS Management Consoles, CLI, or API are all accessible to users with such a policy.

Identity-Based Policies

• Users may link JSON permission policy documents to an identity, like an IAM user, role, or group, using an identity-based policy. Those regulations regulate the circumstances, resources, and behaviors that a given identity may do in AWS Authentication Methods.
• Inline policy and controlled policy are additional categories for identity-based policy. A particular user, group, or position is directly affected by the inline policy.
• In the AWS account, the user may connect managed policy to several users, groups, and roles as a stand-alone policy. AWS-controlled policy and client-managed policy fall under the managed policy category.

In the Iam Console, Actions Are Grouped Using the Following Access Level Classifications:

• List
  Allow the service to list resources to determine whether an object exists. This level of access allows actions to list objects but not examine the contents of resources. Most List access level actions cannot be done on a particular resource. You must specify All resources ("*") when creating a policy statement with these actions.
• Read
  Allows you to read but not alter the contents and characteristics of the service's resources. The Amazon S3 operations GetObject and GetBucketLocation, for example, have Read access.
• Write
  Provide authorization to create, destroy, or change resources in the service. The Amazon S3 operations CreateBucket, DeleteBucket, and PutObject, for example, have to Write access levels.
• Permissions Management
  It entails granting or modifying resource permissions in the service. Most IAM and AWS Organizations policy actions, for example, have the Permissions management access level.

Permission Boundaries

• The additional feature called a permissions boundary enables you to restrict the number of permission that such an identity-based policy can provide to an IAM object. A permission limit can be established for an entity. Therefore, only those operations are permitted by such an entity's identity-based policy and authorization limits of AWS Authentication Methods.
• The boundaries of the permission do not apply to the resource-based policy that identifies the users or roles as the principal. Any of the following policies that explicitly refuse take precedence over the permit.
• AWS Organizations provides policy-based management for many AWS accounts. With Organizations, you can establish groups of accounts, automate account creation, and apply and manage policies for those groups. Organizations allow you to administer rules across numerous accounts from a single location, eliminating the need for bespoke scripts and tedious processes.

Service Control Policies (SCPs)

• The maximal permission for the organizations or organization unit (OU) in AWS Organization was specified in SCPs, which are JSON policies.  AWS Organization is a solution for organizing and administering the whole of the company's Aws services from a single location.
• Users may deploy services controls policy (SCPs) to all or any of the accounts provided they activate each of an organization's functionalities. The SCP restricts access for the entity in the member's account, including every root user of AWS accounts in AWS Authentication Methods.

Session Policies

• Whenever users programmatically establish a short session for just a role or federation user, users can supply advanced policies known as session policies as just a parameter.
• IAM entities (user or role) that created the sessions, as well as the sessions policies, determine the permission for the sessions. Another form of permission is a resource-based policy.