AWS Certified Solutions Architect Professional - Identity Federation & Cognito

Introduction

Quick note about AWS Identity Federation & Cognito. This post is a quick note from the course Ultimate AWS Certified Solutions Architect Professional of Stephane Maarek. The only purpose of this post is summary, if you want detail learning, please buy a Stephane Maarek's course.

Identity Federation

Give user outside of AWS permission to acess AWS resource in your account. We don't need create IAM user because we want manage user outside AWS.

Identity Federation work like that:

• Fist, we setting trust relationship between Identity Provider and AWS. We tell AWS that it's fine to get an identity from this Provider.
• Then the user perform a login to Identity Provider and receive back temporary credentials for AWS.
• The user will access AWS using these temporary credentials.

Use cases

1. We build the application (web/app) that needs access to AWS resource. For exampe, we need build the web app that allow only login user can upload file to AWS S3 bucket.

2. A corporate has its own identity system and they want user their system. For example, a corporate use window server and have Active Directory identity system.

Identity Federation implement

Identity Federation have some way to implment:

• SAML 2.0 Federation.
• Custom Identity Borker.
• Web Identity Federation.
• Single Sign-On (SSO).

SAML 2.0 Federation

SAML stand for Security Assertion Markup Language 2.0 (SAML 2.0). Its primary role in online security is that enable you to access multiple web applications that using one set of login credentials.

Support integration with Microsoft Active Directory Federation Service (ADFS) or any SAML 2.0 that compatible identity provider (IdP) with AWS.

To receive temporary credentials, identity provider use the STS API AssumeRoleWithSAML.

Note, SAML is the old way, AWS SSO Federation is the new and simpler way. We will talk about this later.

Use SAML 2.0 Federation to receive credentials for AWS API Access

For example, The user login to Identity Provider use SAML 2.0 and receive back temporary credentials for access S3 bucket.

1. User perform authentication to the IdP.
2. IdP will verify user through an Identity Store.
3. Return SAML Assertion if login is successful.
4. The user can call the STS API AssumeRoleWithSAML, and STS will verify the assertion and return back temporary credentials if the assertion is trust.
5. The user can access S3 bucket with temporary credentials.

Use SAML 2.0 Federation to receive credentials for AWS Console Access

The left side is similar to the above example, but the right side have a little different. We use SAML 2.0 Federation for access AWS Console.

1. User perform authentication to the IdP.
2. IdP will verify user through an Identity Store.
3. Return SAML Assertion if login is successful.
4. The user post to AWS sign-in url that end with /saml.
5. Request temporary credentials.
6. Return back for user a sign-in url.
7. User redirect to AWS Console.

Use SAML 2.0 Federation with Active Directory

The right side is similar to the above example, but the left side have a little different. We use SAML 2.0 Federation with Active Directory for access AWS Console.

Custom Identity Borker

Use only if Identity Provider is not compatible with SAML 2.0, the broker application authenticates users, requests temporary credentials for users from AWS, and then provides them to the user to access AWS resources.

1. User browse to a URL and access custom identity broker.
2. Identity Borker authenticates users.
3. If user able to login, Identity Borker will requests temporary credentials.
4. Identity Borker return token or url back to user.
5. User use token or url to access AWS resources.

This scenario is similar to the previous one (a mobile app that uses a custom authentication system), except that the applications that need access to AWS resources all run within the corporate network, and the company has an existing authentication system.

Note, Custom Identity Borker is the old way, AWS SSO Federation is the new and simpler way.

Web Identity Federation

With web identity federation, you don't need to create custom sign-in code or manage your own user identities. Instead, users of your app can sign in using a well-known external identity provider (IdP), such as Login with Amazon, Facebook, Google, or any other OpenID Connect Compatible IdP.

Without Cognito (Not recommended by AWS)

1. Client login into the Third Party Identity Provider.
2. The Web Identity Token return back to the clients.
3. The client will call a STS AssumeRoleWithWebIdentity API with Web Identity Token to receive temporary credentials.
4. The STS return back to client temporary credentials.
5. Client access AWS resources.

With Cognito (Recommended by AWS)

With Cognito it's a little bit more secure and more simple.

1. Client login into the Third Party Identity Provider.
2. The ID Token return back to the clients.
3. The app uses Amazon Cognito API operations to exchange the Login with ID Token.
4. Amazon Cognito return back Cognito Token to client.
5. The app requests temporary security credentials from AWS STS, passing the Amazon Cognito token.
6. STS return back temporary credentials to client.
7. The temporary security credentials can be used by the app to access any AWS resources.

End

End quick note about AWS Identity Federation & Cognito.