Hello, and welcome to this final lecture where I just want to briefly summarize some of the points that we have looked at. You should now have an understanding and overview of what the Identity and Access Management service is and does, and the different components of the service that allows you to effectively secure access of your identities to your AWS resources.

We started off by looking and understanding what is meant by IAM, how this linked authentication authorization and access control, which are used heavily within the service.

Next we looked at the different components of the service, starting with users, groups, and roles. Let me just quickly provide an overview of these three components again.

I defined users as objects representing an identity which are used in the authentication process to your AWS account. User objects are created to represent an identity. This could be a real person within your organization who requires access to operate and maintain your AWS environment. Or it could be an account to be used by an application that may require permissions to access your AWS resources programmatically.

IAM groups are objects much like user accounts, however, they are not used in any authentication process. They are used to authorize access to AWS resources through the use of AWS policies. The groups contain users, and these groups will have IAM policies associated that will allow or explicitly deny access to AWS resources.

IAM roles allow user of AWS services and applications to adopt a set of temporary IAM permissions to access a AWS resources. This could be required to enforce security best practices. Following this section, I then explained more about IAM policies. I explained that IAM policies are formatted as JSON documents and each policy will have at least one statement where the structure may look like the following example.

A full explanation was given as to what each item define within the policy to relay to start creating your own custom policies. We also learnt that there were two types of policies, AWS Managed and Customer Managed. AWS Managed Policies are predefined IAM policies that are already configured allowing you to assign them as required.

Customer Managed Policies are created and modified by the customer, so essentially any other policy outside of the AWS Managed Policies.

After looking at policies, I explained what Multi-Factor Authentication was and why it is used. For many cases the verification of an identity requires more than just a password to confirm the identity.

In these cases, typically those identities with a higher level of authorization these users should have MFA associated their accounts as an additional verification step within the authentication process. This adds another layer of security attached the identity. Using and MFA device which can be a physical token or a virtual device a random six digit number is generated for a very short period of time, usually seconds. This number then has to be entered as a part of the authentication process.

Following MFA, I looked at how Federation can be used as a single sign on approach. Identity Federation allows users from identity providers external to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account.

As a part of the configuration process to implement Federated authentication a trust relationship between the identity provider and your AWS account must be established. AWS supports two types of identity providers, OpenID Connect, OIDC, and SAML 2.

OIDC Federation allows authentication between AWS resources and any public OpenID Connect provider such as Facebook, Google, or Amazon.

SAML 2 based Federations can allow your existing active directory users to authenticate to your AWS resources allowing for a single sign on approach. SAML stands for Security Assertion Markup Language.

Finally, I quickly covered some of the other features of AWS which explain how to create a password policy for users within IAM and how this could be configured to reflect your own internal security standards.

I then gave a high level overview of how KMS Customer Master Keys can be created from within the IAM console.

Thank you for taking the time to view this course and if you have any feedback, positive or negative I would very much appreciate your comments.

That now brings us to the end of this course. I wish you continued success with any future development and learning of cloud computing here at CloudAcademy.

Thank you.