Introduction to Identity Access Management

Essentially IAM allows you to manage users and their level of access to the AWS console.
IAM is very important for administrating a companies AWS account in real life.

• Centralised control of AWS account.
• Shared access to your AWS account.
• It gives granular permissions. (User John Smith to have access to have read only access to dynamoDB)
• Identity Federation (including Active Directory, Facebook, Linkedin etc). Login to FB/Linkedin and use AWS resources. 
• Multifactor authentication.
• Provide temporary access for users/devices and services where necessary.
• Allows you to set up your own password rotation policy (how often users have to change the password, also allows to have password policy like small case, upper case, numerical etc.,).
• Integrates with many different AWS services.
• Supports PCI DSS Compliance. PCI DSS Compliance is an order process that has to go thorough for online payments when you are handling the payments ourselves, if we are using any third party vendors like PayPal or any other service they take care of the PCI DSS Component.
• IAM is global it doesn't require any region. So we cannot select any region as such.

Critical Terms :

• Users - End Users (People using)
• Groups - A collection of users under one set of permissions (Developers, Human Resources, Finance dept.,).
• Roles - You create roles and can then assign them to AWS resources.
• Policies - A document that defines one or more permissions. We create a policy document and assign it to a user/group/role.

Hands On:

• The first time we login in to AWS console, we are actually logging in with the root account.
• In order to access IAM, we have to select IAM under the Security, Identity and Compliance section.

• We can see that the five sections out of which only the first one is complete and the rest are incomplete.
• One other thing we can observe is that IAM doesnt have any location, it is specified as global.
• So the users, groups and roles are available all across the world, doesnt matter on a location.

• We can customize the sign-in link by clicking on customize and giving our own DNS name space, which is unique.
• The number that comes up on the link is the AWS account number which can also be accessed from My Account.

Step 1: Activate MFA(MultiFactor Authentication) on your root account:
Root account is the email id that we used to login in to the AWS, which gives root access(highest power).

Managing a MFA can be done in two ways using the virtual device or a hardware device.

Google Authenticator app is generally used for authentication by scanning the QR code.

Download the app, scan the QR code and enter the activation key twice and thats it the virtual device is all set up for the root account.

Step 2:  Manage Users:
Click on manage users, give the names of the users.

Access Type:
Programmatic access is used for the developers where they can access AWS programmatically using command line or their code using access key id and secret access key.
Management console access is by using the AWS console.

The next step is to give permissions to the users that we have created either by copy users to a group(inheriting the permissions that the group has) or copy the permissions from an existing group or by attaching existing policies directly.

When you try to create a group, we can attach a policy from the existing policies.

In the final step of adding the users we can see the secret access key and the tokens for the users that can be used to access AWS programmatically.

For the users to login to console they will be needing the user name and the password.
These cannot be used vice versa.

Console - User Name and Password
Programmatic acess - token and access key

We can create new groups attach policies and add users to those groups.

We can even add individual permissions/policies to the users.

Step 5 : Apply an IAM password policy

Creating Roles:

AWS Service Roles; roles for different services. Select one of the services roles and then select the policy (which basically specifies what kind of access to which service)
Role for Cross-Account Access; which is for one service to be able to access another service.
Role for Identity Provider Access; used when external applications like FB, LinkedIn or anyother services have to talk to AWS.

Security Token Service (STS):-

 Grants users limited and temporary access to AWS resources. Users can come from three sources:

• Federation (Active Directory)-> Uses Security Assertion Markup Language(SAML).
  -> Grants temporary access based off the users Active Directory credentials. Does not need to be a user in IAM.
  -> SSO allows users to log in to AWS console without assigning IAM credentials.
• Federation with mobile Apps-> Use Facebook/Amazon/Google or other OpenID providers to log in.
• Cross Account Access
  -> Lets users from on AWS account access resources in another.

Key Terms:

1. Federation: combining or joining a list of users in one domain (such as IAM) with a list of users in another domain (such as Active Directory, Facecbook etc)
2. Identity Broker: a service that allows you take an identity from point A and join it (federate it) to point B.
3. Identity Store:  Services like AD, FB, Goole etc.,
4. Identities : A user of a service like FB. etc..

 Process of using STS to connect to LDAP:

1. Develop an Identity Broker to communicate with LDAP and AWS STS.
2. Identity Broker always authenticates with LDAP first, then with AWS STS.
3. Application then gets temporary access to AWS resources. 

Active Directory Federation:

->When someone is working from home and need to login to AWS console.
->They browse to a url and access using AD username and password.
->Browser then receives a SAML assertion in the form of an authentication response from ADFS.
->Browser posts the SAML assertion to the AWS sign-in endpoint for SAML. Behind the scenes,      sign-in uses the AssumeRoleWithSAML API to request temporary security credentials and then constructs a sign-in URL for the AWS Management Console.
-> Browser receives the sign-in URL and is redirected to the console.

User Always get authenticated against the AD first and then gets assigned a temporary URL for authentication to sign in to the AWS.

Web Identity Federation: - 
-> Uses call AssumeRoleWithWebIdentity (using FB, Google etc.,)
-> We basically sign in to either FB or google and then get a temporary token after getting authenticated against the same and continue to use AWS resources.