Federation and Single Sign On

In this lesson we cover identity federation and single sign‑on (SSO) for AWS. Topics include common identity challenges, SSO fundamentals (SAML / OIDC / STS), AWS IAM Identity Center (formerly AWS Single Sign‑On), permission sets and boundaries, automation, and monitoring/auditing. The goal is to make identity flows and tooling clear so you can design and operate identity at scale across multiple AWS accounts.

This lesson emphasizes conceptual flows and integration patterns rather than memorizing CLI or CloudFormation syntax. Focus on understanding the SAML/OIDC → STS exchange, permission set design, and how IAM Identity Center integrates with corporate identity providers.

Common enterprise goal: federate your corporate identity provider (IdP) with AWS so users avoid separate IAM users in each account. The diagram below illustrates a typical SAML/STS flow: users authenticate with an external IdP, receive an assertion or token, and AWS STS issues temporary credentials used to assume roles across accounts.

A technical diagram titled "Identity Federation and SSO: Simplifying Secure Access to AWS" showing users authenticating via an external identity provider/LDAP and AWS IAM Identity Center. It illustrates the SAML/STS flow and IAM cross-account role assumptions used to grant access to multiple AWS accounts and resources (RDS, EC2).

Key points about the SAML/STS flow:

The browser or client is redirected to the corporate IdP (examples: AD FS, Okta, PingFederate).
The IdP returns a signed SAML assertion or web identity token (OIDC/OAuth).
AWS validates the assertion and Security Token Service (STS) issues temporary credentials that allow the user to assume a role in one or more AWS accounts.
STS is an API/service responsible for temporary credentials; it is central to federation even though it is not a UI management surface.

Centralizing access via federation reduces the administrative overhead of creating and maintaining duplicate IAM users across many AWS accounts.

A diagram comparing "Separate Identities" (multiple identical user accounts mapped to different AWS accounts) with "Federated Identity" (a corporate directory and single sign-on service providing access to an AWS account). It highlights how SSO centralizes access versus managing many individual IAM users.

The administrative cost of non‑federated approaches grows quickly as accounts, teams, and regions multiply. Compliance programs typically require integration with a centralized identity system.

A slide titled "Scenario: The Identity Management Challenge" showing a bar chart of Administrative Overhead Metrics. Three colored bars compare Federated Users, IAM Users (set 1), and IAM Users (set 2), with overhead rising from the federated group to the second IAM set.

Identity federation fundamentals

An application or AWS console flow redirects the user to an IdP to obtain a SAML assertion or OIDC token.
The assertion/token is exchanged with AWS STS for temporary AWS credentials.
The browser or client uses these temporary credentials to call AWS APIs or access the console.

Types of federation (at a glance)

Federation Type	Typical Identity Providers	Common Use Cases
SAML 2.0	Microsoft ADFS, Okta, PingFederate, Azure AD	Enterprise SSO for console and cross-account role assumption
Web Identity (OIDC/OAuth)	Google, Facebook, Apple, other OAuth providers	Mobile/web social login, short-lived access for apps (use with Cognito)
Custom Identity Broker	Internal broker, API gateway that mints tokens	Organizations requiring bespoke auth flows or token translation

A presentation slide titled "Identity Federation Fundamentals" showing a comparison table of federation types (SAML 2.0, Web Identity Federation, Custom Identity Broker) with descriptions, typical identity providers, and use cases. Examples listed include Microsoft ADFS/Okta, Google/Facebook/Apple, and use cases like enterprise SSO, mobile/web social login, and custom auth workflows.

SAML 2.0: brief recap

SAML = Security Assertion Markup Language.
It establishes trust between the service provider (SP — e.g., AWS) and the identity provider (IdP).
Typical flow: user requests access → SP redirects to IdP → user authenticates → IdP returns a signed SAML assertion → SP validates assertion and issues temporary credentials.

A SAML 2.0 federation diagram showing a user, a browser, AWS as the service provider, and an Identity Provider (e.g., Active Directory/Okta) connected by numbered arrows. A five-step list at the right summarizes the flow: access AWS, request SAML, redirect to IdP, user authenticates, and return a signed SAML assertion.

Example: fragment of SAML identity provider metadata. Recognize the structure (EntityDescriptor, IDPSSODescriptor, key information). You do not need to memorize every element, but understanding metadata exchange helps when configuring trust between IdP and AWS.

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
                  entityID="https://idp.example.com/adfs/services/trust">
  <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>
MIIC+DCCAeCgAwIBAgIBADANBgkqhkiG9w0BAQUFADCBizELMAkGA1UEBhMCVVMx...
          </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <!-- Endpoints such as SingleSignOnService URLs would appear here -->
  </IDPSSODescriptor>
</EntityDescriptor>

Web Identity Federation (WIF) flow

The user authenticates with an external web identity provider (for example, Google).
The provider returns an OIDC / OAuth token.
The token is exchanged with AWS STS to obtain temporary AWS credentials used to assume a role.
Amazon Cognito identity pools can simplify token exchange and identity mapping for mobile/web apps.

A diagram titled "Web Identity Federation" showing a user authenticating with a web identity provider (Google/Facebook) to obtain a token, then calling AWS Security Token Service (STS) to receive temporary AWS credentials. The left panel lists the "Without Cognito" steps for that flow.

AWS IAM Identity Center (AWS SSO)

IAM Identity Center is AWS’s managed SSO solution. It provides a user portal, centralized user/group provisioning, account assignments, and permission sets.
It enables a single user directory (built-in Identity Center directory, AWS Managed Microsoft AD, or an external SAML IdP) to manage access across an AWS Organization.
Use IAM Identity Center to centralize account access, standardize permission sets, and simplify the user experience across multiple AWS accounts.

A diagram of AWS Single Sign-On (IAM Identity Center) architecture showing identity sources (Identity Center directory, AWS Managed AD, external SAML IdP) connecting to the IAM Identity Center. It illustrates an access portal and multiple AWS accounts with numbered steps for provisioning, account assignments/permission sets, sign-in, and access management.

Permission sets

A permission set is a collection of AWS managed policies, inline policies, and session settings (duration, relay state). You assign permission sets to users or groups via IAM Identity Center for specific AWS accounts.
Permission sets are easier to manage than creating role/policy attachments per account.

Example permission set definition (YAML with inline JSON policy). Use this as a conceptual template — adapt for your environment.

PermissionSet:
  Name: "ReadOnlyAccess"
  Description: "Read-only access to example resources"
  SessionDuration: "PT8H"  # ISO 8601 duration (8 hours)
  RelayState: "https://console.aws.amazon.com/"
  ManagedPolicies:
    - "arn:aws:iam::aws:policy/ReadOnlyAccess"
  InlinePolicies: |
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "s3:ListBucket",
            "s3:GetObject"
          ],
          "Resource": [
            "arn:aws:s3:::example-bucket",
            "arn:aws:s3:::example-bucket/*"
          ]
        }
      ]
    }
AccountAssignments:
  - AccountId: "123456789012"
    PermissionSetName: "ReadOnlyAccess"
    PrincipalType: "USER"
    PrincipalId: "user-abc123"
  - AccountId: "210987654321"
    PermissionSetName: "ReadOnlyAccess"
    PrincipalType: "GROUP"
    PrincipalId: "group-devops"

Create multiple permission sets (e.g., DeveloperFullAccess, ReadOnlyQA, ProjectXLimitedAccess) and assign them across accounts and groups to standardize access.

A diagram titled "Permission Sets and Access Control" showing permission sets (DeveloperFullAccess, ReadOnlyQA, ProjectXLimitedAccess) on the left mapped to users/groups (group-dev-team, group-qa, user-jdoe) across three AWS accounts on the right. It illustrates which groups/users have which permission sets in each account.

Directory integration considerations

Directory Option	When to use	Key considerations
AWS Managed Microsoft AD / on‑prem AD	Enterprises with existing AD investments	Trusts, group/attribute mapping, Kerberos/LDAPS integration
IAM Identity Center built‑in directory	Small-to-medium teams or demo/test environments	Simpler setup, limited AD features
External SAML/OIDC IdP (Okta, Azure AD)	SaaS IdP or centralized corporate IdP	Federation metadata, SCIM provisioning, attribute mapping
Amazon Cognito user pools	App-centric auth for mobile/web apps	OIDC/OAuth flows, user pool groups, integration with social providers

A presentation slide titled "Directory Integration Options" with three colored panels: Active Directory Integration, Cloud‑Native Directory Options, and Synchronization Considerations. Each panel lists bullet items like AWS Managed Microsoft AD, IAM Identity Center, Amazon Cognito, and user/group provisioning and attribute mapping.

CLI and programmatic access with IAM Identity Center

The AWS CLI supports SSO login flows. Example commands: aws configure sso and aws sso login. The user authenticates via browser and the CLI stores short‑lived credentials for API calls.
Session durations, MFA enforcement, and permission boundaries apply to both console and programmatic sessions.

Multi‑account access strategy

IAM Identity Center is designed to work with AWS Organizations. Define permission sets centrally and assign them to accounts in the organization.
Typical user flow:
1. Authenticate with corporate IdP (MFA enforced as required).
2. Access IAM Identity Center portal.
3. Select target account and permission set.
4. IAM Identity Center (via STS) issues temporary credentials.
5. User accesses the selected account and resources.

A diagram titled "Multi-Account Access Strategies" showing identity flow from a Corporate Identity Provider and Permission Sets into AWS IAM Identity Center and AWS Organization. The organization branches into OUs (Production, Development, Shared Services, Security) with individual AWS accounts listed under each.

User access journey (console or programmatic) overview:

A diagram titled "Multi-Account Access Strategies" showing a user journey across AWS accounts: boxes flow from Corporate User → IdP Authentication (MFA) → AWS IAM Identity Center → Account and Permission Set selection → STS credential generation → AWS console access → environment resources and cross-account access monitoring. It's a visual flowchart of the normal user access process for multi-account AWS environments.

Programmatic access path (CLI / SDK) follows the same concepts but uses the SSO login flow to provision credentials for the CLI or SDK.

A flowchart titled "Multi-Account Access Strategies — Programmatic Access Path" showing the user journey for AWS multi-account access, from a corporate user through IdP/MFA and the AWS IAM Identity Center to account and permission selection, STS credential generation, console/CLI access, environment resources, and cross-account monitoring.

Automation: CloudFormation and IaC for permission sets

AWS CloudFormation supports AWS::SSO::PermissionSet and AWS::SSO::Assignment so you can automate permission set creation and account assignments.
You are not expected to memorize the full CloudFormation syntax for exams, but know that automation and infrastructure-as-code for permission sets and assignments is supported.

Example CloudFormation (conceptual) showing a permission set and an assignment:

AWSTemplateFormatVersion: '2010-09-09'
Description: Creates IAM Identity Center permission sets and assigns them to users/groups.

Parameters:
  InstanceArn:
    Type: String
    Description: ARN of the IAM Identity Center instance

Resources:
  AdminPermissionSet:
    Type: 'AWS::SSO::PermissionSet'
    Properties:
      Name: 'AdminAccess'
      Description: 'Permission set for administrators'
      InstanceArn: !Ref InstanceArn
      SessionDuration: 'PT4H'
      ManagedPolicies:
        - 'arn:aws:iam::aws:policy/AdministratorAccess'
      InlinePolicy: !Sub |
        {
          "Version":"2012-10-17",
          "Statement":[
            {
              "Effect":"Deny",
              "Action":[
                "organizations:LeaveOrganization",
                "organizations:CloseAccount"
              ],
              "Resource":"*"
            }
          ]
        }

  DevsAssignment:
    Type: 'AWS::SSO::Assignment'
    Properties:
      InstanceArn: !Ref InstanceArn
      PermissionSetArn: !GetAtt AdminPermissionSet.PermissionSetArn
      PrincipalId: !Ref PrincipalId
      PrincipalType: 'GROUP'
      TargetId: !Select [0, !Ref AccountIds]
      TargetType: 'AWS_ACCOUNT'

Monitoring and auditing federated access

CloudTrail should be enabled to capture API calls, including federation and SSO events.
Collect Identity Center logs, IdP authentication logs, and CloudTrail into a centralized analytics platform or SIEM to detect anomalies (unusual geolocations, privilege escalation, or unexpected account activity).
Retain logs according to compliance requirements and use automated alerting/analytics for privileged access reviews.

Best practices

Area	Recommended Controls
Authentication	Enforce MFA, use strong IdP policies, and require device checks where possible
Authorization	Apply least privilege, use scoped permission sets and short session durations
Delegation controls	Use permission boundaries and deny statements to limit delegated privileges
Lifecycle	Automate provisioning/deprovisioning and regularly review unused principals
Observability	Centralize CloudTrail, Identity Center logs, and IdP logs; monitor for anomalous activity

Protect the federation trust: ensure IdP metadata is validated, rotate signing keys, enforce MFA, and monitor token usage. A compromised IdP can lead to broad access across your AWS Organization.

A presentation slide titled "Federation and SSO Best Practices" showing security and operational recommendations. The security section lists items like enforce MFA, least privilege, short sessions, and review access regularly with brief implementation notes.

Maturity model — how organizations typically evolve

Basic Federation: SAML-based SSO with manual provisioning.
Standardized: Adopt IAM Identity Center, consistent permission sets, enforced MFA.
Optimized: Automated lifecycle/provisioning, permission boundaries, centralized monitoring.
Adaptive: Just-in-time access, risk-based adaptive controls, dynamic privilege elevation.

A slide titled "Federation and SSO Best Practices" showing four maturity stages — Basic Federation, Standardized, Optimized, and Adaptive — each with brief bullet points (e.g., SAML, IAM Identity Center, automated lifecycle, just‑in‑time access). The stages are mapped to labels like Basic controls, Standardized MFA, Least privilege, and Adaptive security.

Summary

Federation + SSO reduces administrative overhead, improves security posture, and simplifies compliance across multi‑account AWS environments.
Understand SAML/OIDC/Web Identity flows and the role of STS in issuing temporary credentials.
Use IAM Identity Center permission sets to centralize and standardize access across AWS Organizations.
Automate provisioning where possible; enforce MFA, least privilege, and centralized logging; and continuously monitor for anomalous access.

Links and references

Introduction

Domain 1 - SDLC Automation

Domain 2 - Configuration Management and IaC

Domain 3 - Resilient Cloud Solutions

Domain 4 - Monitoring and Logging

Domain 5 - Incident and Event Response

Domain 6 - Security and Compliance

Federation and Single Sign On

Watch Video