Federation and SSO

SAML 2.0 (Security Assertion Markup Language) enables single sign-on between your corporate identity provider (IdP) and AWS. Users authenticate with the IdP and receive temporary AWS credentials without separate AWS logins.

The SAML flow works as follows: the user accesses the AWS Management Console, is redirected to the corporate IdP, authenticates, receives a SAML assertion, and posts it to the AWS SAML endpoint. AWS validates the assertion and grants temporary console access.

Configuration Steps:

1. Create an IAM role with a trust policy for the IdP (SAML provider ARN as principal)
2. Register the SAML provider in IAM using the IdP metadata document
3. Configure the IdP with AWS endpoint URLs and the IAM role ARN

For example, a company using Azure AD as their IdP configures SAML federation so employees log in with their corporate credentials. The SAML assertion includes role attributes that map to IAM roles. Developers get a DeveloperRole while finance users get a FinanceRole.

Attribute Mapping translates IdP attributes to AWS role session names and tags. Map email to RoleSessionName so CloudTrail logs show which corporate user performed each action.

SAML federation supports both console access and programmatic access via the AWS CLI using aws sts assume-role-with-saml.

AWS IAM Identity Center (formerly AWS SSO) is the recommended approach for managing access to multiple AWS accounts and business applications. It provides centralized authentication and authorization.

Permission Sets define the level of access users have in each account. A permission set is a collection of administrator-defined policies that specify what users can do. For example, a ReadOnly permission set attaches the ReadOnlyAccess managed policy, while a FullAdmin permission set attaches AdministratorAccess.

Account Assignments map users or groups to permission sets in specific accounts. A user assigned the DeveloperRole permission set in Account A and ReadOnlyRole in Account B can perform different actions in each account through a single login.

Configuration Flow:

1. Connect an external identity provider (Azure AD, Okta, PingIdentity) or use the built-in Identity Center directory
2. Create permission sets with the desired policies
3. Assign users or groups to permission sets in target accounts
4. Users access the Identity Center portal and see assigned accounts

For example, a startup with 5 AWS accounts (development, staging, production, logging, security) uses Identity Center. Developers get DeveloperRole in development and staging, ReadOnlyRole in production, and no access to logging or security accounts.

Identity Center also integrates with business applications like Salesforce and Box, providing a single portal for all corporate application access.

OpenID Connect (OIDC) federation enables web and mobile applications to obtain temporary AWS credentials using external identity providers like Google, Facebook, Amazon, or corporate OIDC providers.

Web Identity Federation allows users to authenticate with a supported web identity provider and receive temporary AWS credentials. The application redirects to the IdP, receives an OIDC token, and exchanges it for temporary credentials via the AWS AssumeRoleWithWebIdentity API.

For example, a mobile app allows users to sign in with their Google account. The app sends the Google OIDC token to AWS, which validates it and returns temporary credentials scoped to the user's identity.

OIDC for Workload Identity is used for workloads that need to authenticate to AWS without long-term credentials. GitHub Actions, for example, can assume an IAM role by presenting a GitHub-issued OIDC token. This eliminates the need to store AWS access keys as GitHub secrets.

A GitHub Actions workflow assumes a role:

- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
    aws-region: us-east-1

The trust policy for the role specifies GitHub as the principal and uses conditions to verify the repository and branch:

"Condition": {
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:org/repo:ref:refs/heads/main"
  }
}

This ensures the role can only be assumed from the specified repository and branch.

Amazon Cognito provides user pools for authentication and identity pools for authorization. Identity pools grant temporary AWS credentials to users authenticated by any supported provider.

User Pools handle user registration, sign-in, and account recovery. They manage user directories and support MFA, password policies, and custom attributes. User pools are a managed user directory, not an identity provider.

Identity Pools (Federated Identities) exchange tokens from any supported provider (Cognito User Pools, Google, Facebook, Apple, SAML) for temporary AWS credentials. The temporary credentials grant access to AWS services based on IAM policies.

Unauthenticated Access allows identity pools to grant limited AWS credentials to anonymous users. For example, a public mobile app might allow unauthenticated users to read public content but require authentication for writing comments.

Token-Based Access: Identity pools validate tokens from the configured provider and return temporary credentials. The credentials are scoped to the IAM role mapped to the identity type (authenticated or unauthenticated).

For a real-time chat application, users authenticate via Cognito User Pools. The identity pool issues temporary credentials with permissions to read/write to a DynamoDB table for their own messages. Unauthenticated users can view public channels but cannot send messages.

Sync Configuration across devices uses Cognito Sync (now part of AppSync) to persist user preferences and application state. The temporary credentials from the identity pool grant access to the Cognito Sync dataset.