Hello and welcome to this lecture where I shall be discussing identity federation, explaining what it is and the different types of federation that is available and how to create identity providers within IAM. Identity federation allows you to access and manage AWS resources even if you don't have a user account within IAM.

Identity federation allows users from identity providers which are external to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account. An example of an identity provider can be your own corporate Microsoft Active Directory. Federated access will then allow the users within it to access AWS.

Other forms of identity providers can any OpenID Connect, OIDC, web provider. Common examples of these are Facebook, Google and Amazon. If you want to understand more about OpenID Connect, please see the following link. As a result, if you need users to access AWS resources that already have identities that could be used as an identity provider, then you could allow access to your environment using these existing accounts instead of setting each of them up a new identity within AWS IAM.

The benefits of this is twofold. It minimizes the amount of administration required within IAM and it allows for a single sign-on solution. As the vast majority of organizations today are using Microsoft Active Directory, using MS-AD is an effective way of granting access to your AWS resources without going through the additional burden of creating potentially hundreds of IAM user accounts.

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, also often referred to as web identity federation, and SAML 2. OpenID Connect allows authentication between AWS resources and any public OpenID Connect provider such as Facebook, Google or Amazon.

When it's set up and configured, andaccess request is made by a user to an AWS resource. Though identity provider credentials will be used to exchange an authentication token for temporary authentication credentials. These temporary credentials with pre-configured permissions allow authorized access to resource as required.

For this example the process could be managed more effectively with the use of Amazon Cognito which helps manage user sign-in to mobile and web apps through federated access. For more information on Amazon Cognito, please see the links on screen: https://cloudacademy.com/blog/amazon-cognito-manage-mobile-data/ - https://aws.amazon.com/cognito/. SAML 2 base federations can allow your existing Active Directory users to authenticate to your AWS resources, allowing for a single sign-on solution.

SAML stands for Security Assertion Markup Language and allows for the exchange of security data, including authentication and authorization tokens to take place between an identity provider and a service provider. In this case the identity provider is a Microsoft Active Directory service and the service provider is AWS.

Once configured, let's take a look at how this Active Directory authentication mechanism is established. This example will assume the user within an organization requires API access to S3, EC2 and RDS. This scenario will also include the use of an AWS service called Security Token Service, STS. The Security Token Service allows you to gain temporary security credentials for federated users via IAM, associated with IAM roles and policies.

More information on STS can found here. Let's look at this in more detail via a diagram.

A user within an internal organization initiates a request to authenticate against the Active Directory Federated Service, ADFS Server, via a web browser using a single sign-on URL.

If their authentication is successful by using their Active Directory credentials, SAML will then issue a successful authentication assertion back to the user's client requesting federated access.

The SAML assertion is then sent to the AWS Security Token Service to assume a role within IAM using the AssumeRoleWithSAML API. More information on this API can be used on the link on screen.

STS then responds to the user requesting federated access with temporary security credentials with an assumed role and associated permissions allowing S3, EC2 and RDS access as per our example.

The user then has federated access to the necessary AWS services as per the role permissions.

This is a very simple overview of how federation is instigated from the user for API access to specific AWS services. Corporate identity federation is always authenticated internally first by Active Directory before AWS.

To use federation within IAM, you must first create an identity provider which is a simple process providing you have the correct information from your chosen identity provider first. This required information is as follows.

For OIDC providers you will need a client ID, also known as an audience, which you will receive once you have registered your application with your identity provider. This ID is usually a unique identifier.

You must also obtain a thumbprint to verify the certificate of your identity provider.

SAML providers. You will need a SAML Metadata document that you can get by using your identity management software from your identity provider. This will include information such as the issuer's name, expiration data and security keys which are used to validate the SAML authentication response from your identity provider.

Further information on these requirements and how to get them is outside of the scope of this course. However, further information on these elements can be found within the IAM user guide with the link on screen.

To create an identity provider for OIDC, the process is as follows. From within the IAM console select identity providers. Next click on create provider. Then select OpenID Connect, enter the URL of the identity provider, enter the client ID, known as the audience, of your application that will communicate with AWS discussed earlier. Supply the thumbprint for service certificate verification. Then create a role for the identity provider, verify the information and click create and the OIDC provider will then be created.

To create a SAML provider the process is slightly different. From within the IAM console select identity providers, click create provider, select SAML, enter a name for the identity provider, point to the SAML metadata document discussed earlier and then verify the information and click create.

This now brings us to the end of this lecture on federation. Following this I shall be looking at a few other features of IAM.