Federation

The idea of Federation in AWS IAM is that it allows organizations to bring existing authentication in form of on-prem identities (MSFT's Active Directory) or online identities (Google Workspace Identity or MSFT Admin center users or MSFT Entra-ID etc) here in AWS and assign permissions to them, i.e. use existing corporate credentials for authentication and authorization into AWS Console, CLI or direct API calls.

Types

AWS supports different types of Federation, as given below:

• Cross Account Access

• SAML 2.0

• Web Identity

• AWS Directory Service

Source: https://d1.awsstatic.com/security-center/SecurityBlog/federated_auth_with_adfs_5.69a994ecc1645a52e53648efaae211cdfcfaa55a.png

Cross Account Access

This can be best understood from the following diagram:

Source: https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2016/11/16/Diagram_KZ_111616_d.png

Please note that temporary security credentials can be valid from 15 minutes to upto 12 hours.

SAML 2.0 - For existing Corporate Users

Security Assertion Markup Language or SAML is an open standard supported by many identity providers (IdPs) such as auth0, Microsoft Active Directory, Azure, Google Workspace Identity etc.

It requires first setting up metadata, which lays the ground rule for how the communication will happen between the IdP and SP (AWS in this case). Once the authentication is done between IdP and user, then SAML assertion document will be sent by IdP to SP to prove that the user is who he/she claims to be and then based on authorization set in AWS based on IAM role, will get access to AWS services.

The following will explain the process better:

Source: https://docs.aws.amazon.com/images/IAM/latest/UserGuide/images/saml-based-sso-to-console.diagram.png

Note that just like there is sts:AssumeRole, for SAML, there is sts:AssumeRolewithSAML and for Web Users, there is sts:AssumeRolewithWebIdentity

Web Identity - For general Web users

Popular method for Application logins. It supports Amazon, FB, Google or any OIDC Connect compatible Identity providers and integrates with Amazon Cognito as identity broker. Best benefit of these is that End-Users don't need AWS account, and they can still login and access AWS resources (like an image within S3 bucket, let's just say via the application) . The IAM Role that has access to the particular resource can be said to be assumed by the user proving his/her identity using above mentioned providers.

Source: https://miro.medium.com/v2/resize:fit:720/format:webp/0*adBXuxmDWcJWCgth.png

AWS Directory Service

There are basically 3 options, Simple AD, AWS Managed Microsoft Active Directory and Active Directory Connector

• Simple AD - Standalone Samba4 powered Active Directory compatible server. Supports Kerberos and does have user accounts, group membership, group policies but no support for MFA, no trust relationships or PowerShell etc. It works well with AWS apps and services such as Amazon Connect, Amazon QuickSight, Amazon WorkDocs, Amazon WorkMail, Amazon Workspaces etc.

• AWS Managed Microsoft Active Directory, as the name suggests, is simply Microsoft AD in the cloud. It is usually a pair of domain controllers which supports almost all features, supports RADIUS, MFA and secure TLS communication. It requires a VPC with two subnets in different availability zones for redundancy, but does not support NAT. This can be used to keep AD-aware workloads on AWS as well as provide SSO to Office365 and other cloud apps. It is also provides connectivity to On-Prem.

Source: https://docs.aws.amazon.com/images/directoryservice/latest/admin-guide/images/ms_ad_use_cases2.png

• Active Directory Connector - A simple gateway to redirect all requests to on-premises Microsoft AD over a VPN connection or AWS direct Connect. It also requires Kerberos pre-auth enabled. It can also be used to join EC2 instances directly to cloud.

Source: https://aws.amazon.com/blogs/security/how-to-connect-your-on-premises-active-directory-to-aws-using-ad-connector/