Hi and welcome back! Let’s take a deeper dive into hybrid environments learn about Web Identity Federation and AWS Cognito.

In my Designing Resilient Architectures course, we learn about hybrid environments, and that a hybrid environment consists of an on-premise network and AWS, and that there are ways to integrate your hybrid environments with your AWS environment.

So lets start with Identity Federation (IDF) which is an architecture where identities of an external identity provider (IDP) are recognized and it allows Single Sign On (SSO). So the credentials of the external user’s external identity is allowed access to your AWS resources or another local system.

So an example of this is when you sign-in to an online application or mobile application and you are allowed to sign in with your Amazon or Google credentials. And the way it works is that application is taking the identity, and allowing access using the credentials of identity provider such as Google, Amazon, etc. This process is known as identity federation. An IDP is simply a provider of identities. Another example of IDP is Micorsoft Active Directory, FaceBook, etc. You use your credentials to log in to these platforms, but can use these credentials to log into others as well.

There are three types of Identity Federation:

Cross account role: this is where a remote account, so a remote IDP, is allowed to assume a role and access your account resources. And we saw this when we switched roles in our AWS organization inside the Designing Resilient Architectures course, we federated our identity to swap our credentials to get access to the other AWS accounts, but the key here is that with AWS cross account roles we are using the same identity provider, AWS.

SAML 2.0 is a standard that is used mostly for on-premise systems, usually Microsoft Active Directory or others, so in this case users can log into AWS with their on-premise credentials.

Web Identity Federation is where we use an IDP (like Amazon, Google, etc.) and allow users to assume roles and access our AWS resources using their IDP credentials. check out AWS Web Identity Federation Playground for a behind the scenes look!

And for SAML 2.0 and Web Identity Federation, AWS uses the Secure Token Service and Cognito for IDF. So the federated identity is verified using an External IDP and provides the identity a secure token, and then the user can swap the secure token for temp credentials into AWS by assuming roles.

STS is AWS services that allows you to receive short term credentials.

Cognito is an AWS’s Web Identity Provider service that brokers the SSO or ID Federation by creating Cognito ID Pools, these are pools of identities. So you can have three different identities, so you have a FaceBook log in, a Google, log in, and an Amazon login, and AWS Cognito allows you to merge these identities and treat them as one identity, bc really all three are your identities anyway. So Cognito acts as an ID broker between your web application and web ID Providers, no additional code it needed.

A user who is wanting to log in to your application, will fist be sent to the IDP like Google, FB, Amazon etc.

When they log into Amazon they will receive an authentication token, that authenticated token will be sent to Cognito, Cognito will respond with temporary security credentials that map to an IAM role to allow access to the required AWS resources in your application.

The updated AWS Certified Solutions Architect exam has added Cognito, and I have seen two types of Cognito questions on Cognito User Pools and Cognito ID Pools.

So a Cognito User Pool are directories used to manage sign up and sign in functionality for mobile and web applications. Your users can sign in directly to the Cognito User Pool, and Cognito User Pool will store their user name and password or they can sign in using Amazon, FB, Google, and then Cognito acts as an ID Broker between the identity provider they choose. Let’s say they choose Amazon and AWS, and when successfully authenticated, a JSON web token will be generated and passed back to the user that maps to an IAM role with the needed permissions. So a Cognito User Pool is all about the access for your users.

Cognito ID Pools are enabled to provide temporary security credentials to access AWS services like S3 or DynamoDB.

Cognito ID Pools are all about authorization of access to AWS resources. So about the services not really about the user.

With Cognito, you and your users can sign up or sign in to your applications, and with Cognito you can grant access for guest users.

With Cognito the user ID is synchronized between multiple devices, so if you update your email address, etc., then those changes are updated to your other devices too. Cognito does this using push synchronization to push these updates and synchronize the user data across multiple devices, and uses SNS (which we will be covering another lesson for the course) to send notifications to all the devices associated with the user ID when that data stored in the cloud changes.

Make sure for the exam you know the differences between Cognito User Pools and Cognito ID Pools.

So remember with AWS, you can not access AWS services, features, products, etc. without a set of credentials, remember by default users have no access. We must explicitly grant permission for our AWS accounts. So you cannot access S3 or an EC2 instance using an IDP, like your Google or Amazon credentials, there has to be an identity exchange behind the scenes.

So lets look at the architecture so we can see what is happening behind the scene:

So let’s start with SAML 2.0 and remember with SAML 2.0 this federation is usually used with Active Directory, so if you see a question on your exam asking with IDP is used with Active Directory, then the answer is probably SAML 2.0.

So for this example, let’s say you are at work, and you need to access AWS, and your office uses Active Directory to manage your corporation’s identities.

So our first step is going to be to log in, so you will browse to your ADFS, which stands for your Active Directory Federation Server, and then you authenticate using your internal AD credentials, or perhaps you are already logged in earlier that morning, but when you authenticate with the ADFS, you are returned a SAML assertion. That SAML assertion is simply a token that proves you are who you say you are, and that SAML assertion is sent to the AWS SSO endpoint, and this endpoint is configured when you design your AWS environment to when you decide to use SAML Federated Identity. The SSO endpoint verifies your ID because there is a trust established between the ADFS server and the SSO endpoint. So the SSO will now communicate with STS and assume a role using the SAML Assertion token that identifies you. The SSO Endpoint will then return to the user a URL redirect, to the AWS Management Console.

Now lets look at Web ID Federation:

Now in this scenario let’s pretend that we are trying to log into an application, well when we browse to the application, we are re-directed for our log in to the IDP Provider and again this can be Google, Amazon, etc. So you log in using your Amazon ID and you are given a token, so now the web application takes your token and then communicates with either STS or Amazon Cognito, and passes in the token received from your Amazon log in and asks STS or Cognito to Assume Role, and then the role assumption happens and you are given temp security credentials and the role is sent back to the user, you can then use those temporary security credentials to access the application

Let’s also look at when we would use Identity Federation bc you will most likely get questions on your certification exam asking when you would use ID federation in different scenarios.

First, it is a great to use Web ID Federation when you have a large enterprise because you already have an existing pool of Identities, and those IDs are used across all of your systems and you want the IDs to be used for the AWS environment as well.

Using Web Identity Federation you can use your AWS resources using SSO. And this is important for the exam, Web ID Federation is a great choice if you have over 5,000 employees bc remember with IAM you can only have 5,000 users in each AWS accounts, so Web Identity federation gives you the ability to allow everyone in the organization the access that they need. IAM can only handle so much, so SAML 2.0 or Web Identity Federation is a great option.

Second, IDF is great for mobile and web applications that require access to your AWS resources. Customers log in with their other identities, Google, Amazon, etc. You do not have to store credentials within your application, and it allows hundreds, thousands, or millions of users, and again IAM again cannot handle this capability.

If you want to grant further access to the users once logged in you can use Cognito to grant them further access using the Cognito ID Pools using the External IDP.

Third, if you are a large organization, you may have tens or hundred of AWS accounts, so you can use your existing corporate IDs, and you can use role switching from the external ID to get credentials to assume roles in other AWS accounts.

I also want to talk about AWS Directory Services because it is service that provides managed directory service. It runs within a VPC, and for high availability make sure your deploy AWS directory services into multiple AZs.

Certain services like Amazon workspaces needs a directory, so AWS Directory Services works great with these types of services and can also be integrated with on-premise systems.

So we have Simple AD which is an implantation and compatible with basic AD functions and can handle 500 users to 5000 users. Simple AD is for simple requirements.

Managed Microsoft AD is an actual Microsoft AD Directory service and you can create a trust relationship with your on-premise directory.

AD Connector provides a proxy request back to an on-premise directory, and is great for proxy identities to integrate with AWS services when you do not want to store any directory information in the cloud.

I hope this helps! I struggled with web identity when I was getting started, so please reach out if you are struggling too! And check out my course, Application Services, on A Cloud Guru!