Study guide
8.2 Identity Federation, SSO & Directory Integration
CompTIA Cloud+ Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud Architecture Fundamentals
1.1 Cloud Service Models & Shared Responsibility 1.2 Cloud Deployment Models & Multi-Cloud Strategies 1.3 High Availability, Resiliency & Redundancy 1.4 Disaster Recovery & Business Continuity 1.5 Evolving Cloud Technologies: AI/ML Services, IoT & Edge Computing
2 Chapter 2: Cloud Compute & Storage Architecture
2.1 Virtualization & Hypervisor Architectures 2.2 Containerization & Microservices Architecture 2.3 Container Orchestration & Kubernetes Architecture 2.4 Cloud Storage Architectures & Performance
3 Chapter 3: Cloud Networking Architecture
3.1 Virtual Private Clouds & Subnetting Architecture 3.2 Hybrid & Multi-Cloud Connectivity 3.3 DNS, Load Balancing & Traffic Routing 3.4 Cloud Network Security Architecture
4 Chapter 4: Workload Assessment & Migration Planning
4.1 Cloud Migration Strategies (The 6/7 Rs) 4.2 Pre-Migration Workload Assessment & Sizing 4.3 Data & Database Migration Methods 4.4 Migration Execution, Cutover & Post-Migration Validation
5 Chapter 5: Infrastructure as Code & Provisioning
5.1 Infrastructure as Code Fundamentals & State Management 5.2 IaC Tooling & Template Authoring 5.3 Provisioning Automation & Image Management 5.4 Deployment Strategies & Release Patterns
6 Chapter 6: Cloud Operations & Lifecycle Management
6.1 Resource Lifecycle & Patch Management 6.2 Cloud Scaling Strategies & Elasticity 6.3 Cloud Cost Management & Optimization (FinOps) 6.4 Capacity Planning & Service Quotas
7 Chapter 7: Cloud Backup, Recovery & Business Continuity Operations
7.1 Backup Strategies, Storage Media & Retention Policies 7.2 Immutable Backups, Vault Locking & Ransomware Defense 7.3 Point-in-Time Recovery & Data Integrity Validation 7.4 High Availability Failover Drills & Chaos Engineering
8 Chapter 8: Cloud Security Controls & Identity and Access Management
8.1 Identity & Access Management, RBAC & ABAC 8.2 Identity Federation, SSO & Directory Integration 8.3 Multi-Factor Authentication, PAM & Machine Identities 8.4 Secrets Management & Cryptographic Credential Hygiene
9 Chapter 9: Data Protection, Vulnerability & Compliance
9.1 Data Encryption, Key Management & Confidential Computing 9.2 Vulnerability Management, Posture Assessment & CWPP 9.3 Container, Workload & Runtime Security 9.4 Cloud Compliance Frameworks & Governance Auditing
10 Chapter 10: DevOps Fundamentals & CI/CD Pipelines
10.1 Version Control Systems & Branching Strategies 10.2 Continuous Integration & Automated Testing Pipelines 10.3 Continuous Delivery, Deployment Automation & GitOps 10.4 Configuration Management & Systems Integration
11 Chapter 11: Cloud Observability & Monitoring
11.1 The Three Pillars of Observability: Metrics, Logs & Traces 11.2 Cloud Monitoring Architecture, Alerting & SLOs 11.3 Centralized Log Aggregation, SIEM & Log Analytics
12 Chapter 12: Troubleshooting Cloud Architecture & Deployments
12.1 Structured Cloud Troubleshooting Methodology 12.2 Troubleshooting Compute, Container & Storage Failures 12.3 Troubleshooting Provisioning, IaC & Automation Failures
13 Chapter 13: Troubleshooting Cloud Networking & Security
13.1 Troubleshooting Cloud Network Connectivity & Routing 13.2 Troubleshooting IAM, Permissions & Encryption 13.3 Troubleshooting Disaster Recovery & Performance Degradation
8.2 Identity Federation, SSO & Directory Integration
Key Takeaways Explain This Topic AI
Identity Federation decouples authentication from cloud platforms by delegating identity verification to a trusted external Identity Provider (IdP), eliminating credential duplication.
SAML 2.0 uses XML-based security assertions to establish trust between an Identity Provider (IdP) and a Service Provider (SP), supporting both SP-initiated and IdP-initiated Single Sign-On (SSO).
OpenID Connect (OIDC) is an identity authentication layer built directly on top of the OAuth 2.0 authorization framework, delivering cryptographically signed JSON Web Tokens (JWT ID tokens).
Hybrid directory synchronization tools (such as Microsoft Entra Connect) synchronize on-premises Active Directory Domain Services (AD DS) to the cloud using Password Hash Sync (PHS), Pass-Through Authentication (PTA), or ADFS federation.
Cloud Security Token Services (STS) enable secure cross-account delegation and workload federation via APIs such as AssumeRoleWithWebIdentity and AssumeRoleWithSAML without static access keys.
Last updated: August 2026
Identity Federation, SSO & Directory Integration
In enterprise cloud environments, managing separate, siloed user accounts across dozens of cloud subscriptions, software-as-a-service (SaaS) platforms, and on-premises systems creates severe security vulnerabilities, compliance failures, and administrative overhead. Identity Federation and Single Sign-On (SSO) resolve this challenge by centralizing identity management into an authoritative Identity Provider (IdP) and establishing cryptographic trust relationships with cloud Service Providers (SPs) .
For the CompTIA Cloud+ (CV0-004) exam, candidates must understand federated protocol flows ( SAML 2.0 , OIDC , OAuth 2.0 ), hybrid directory synchronization models, and temporary credential generation via the Security Token Service (STS) .
1. Identity Federation Protocols: SAML 2.0, OAuth 2.0 & OpenID Connect
Federated identity systems establish a trust boundary between two primary entities:
Identity Provider (IdP): The authoritative system that stores user identities, authenticates credentials, and issues security tokens (e.g., Microsoft Entra ID, Okta, Ping Identity, Google Cloud Identity).
Service Provider (SP) / Relying Party (RP): The cloud application, infrastructure control plane, or service that consumes the security token and provides access to resources (e.g., AWS Management Console, Azure Portal, Salesforce). +-----------------------------------------------------------------------------------------+
- | FEDERATION PROTOCOL ARCHITECTURAL SUITE |
- | |
- | Protocol Layer / Purpose Payload Format Primary Target Use Case |
- | +-------------+-------------------------+-----------------+-------------------------+ |
- | | SAML 2.0 | Enterprise SSO & AuthN | XML Assertions | Enterprise Web SSO, AWS/| |
- | | | | (X.509 Signed) | Azure Management Console| |
- | | OAuth 2.0 | Delegated Authorization | JSON / Opaque | API Token Delegation, | |
- | | | (NOT Authentication!) | Access Tokens | Scoped Resource Access | |
- | | OIDC | User Authentication & | JSON Web Tokens | Mobile Apps, SPAs, CI/CD| |
- | | | Profile Information | (JWT ID Tokens) | Workload Identity, K8s | |
- | +-------------+-------------------------+-----------------+-------------------------+ |
- +-----------------------------------------------------------------------------------------+
- Security Assertion Markup Language (SAML 2.0)
SAML 2.0 is an open, XML-based standard designed specifically for cross-domain web browser Single Sign-On (SSO). SAML exchanges authentication and attribute data via cryptographically signed XML documents called SAML Assertions .
SAML Assertion Components: Contains the Subject (the user identifier/NameID), Conditions (time-bound validity and allowed audience restriction), and AttributeStatements (email, groups, IAM role mappings), signed using the IdP's X.509 private certificate.
SP-Initiated SSO Flow: The user attempts to access the cloud console directly (the SP). The SP generates a SAML AuthNRequest and redirects the user's browser to the IdP login portal. Upon successful authentication, the IdP returns an XML SAML Assertion via browser HTTP POST to the SP's Assertion Consumer Service (ACS) endpoint.
IdP-Initiated SSO Flow: The user logs into their enterprise corporate portal (e.g., Okta dashboard), selects the AWS or Azure application tile, and the IdP automatically posts an unrequested SAML Assertion to the SP's ACS endpoint.
OAuth 2.0 (Open Authorization)
OAuth 2.0 is an open authorization framework that enables third-party applications to obtain limited access to an HTTP service on behalf of a resource owner without sharing the user's password.
Important
Critical Exam Concept: OAuth 2.0 is Authorization, NOT Authentication. OAuth 2.0 issues access_tokens and refresh_tokens designed to grant permissions (e.g., read a calendar or write to an S3 bucket). It does not provide cryptographic identity proof or user profile information.
Common Grant Types:
Authorization Code Grant (with PKCE): Standard flow for web applications and mobile apps.
Client Credentials Grant: Direct machine-to-machine authentication where an automated service accesses back-end APIs without user interaction.
OpenID Connect (OIDC)
OpenID Connect (OIDC) is an identity authentication layer built directly on top of OAuth 2.0. While OAuth 2.0 provides authorization tokens, OIDC extends the flow to return an id_token represented as a cryptographically signed JSON Web Token (JWT) .
JWT Architecture: A JWT consists of three base64url-encoded parts separated by periods ( header.payload.signature ):
Header: Algorithm ( alg : RS256) and token type ( typ : JWT).
Payload (Claims): Issuer ( iss ), Subject ( sub ), Audience ( aud ), Expiration ( exp ), Issued-At ( iat ), and custom claims (e.g., email, department).
Signature: Cryptographic hash of header + payload signed using the IdP's private key, verifiable by the SP using the IdP's public JSON Web Key Set (JWKS).
Comparison Table: SAML 2.0 vs. OpenID Connect
- Feature SAML 2.0 OpenID Connect (OIDC)
- Underlying Standard XML / SOAP JSON / REST / OAuth 2.0
- Token Structure Signed XML Assertion Signed JSON Web Token (JWT)
- Client Footprint Heavyweight (optimized for web browsers) Lightweight (optimized for mobile, web, APIs, CI/CD)
- Transport Method HTTP POST binding / HTTP Redirect HTTP GET/POST with Bearer Headers
Modern Workload Identity Legacy enterprise federation Primary choice for GitHub Actions, Kubernetes, and Cloud STS
2. Cloud Single Sign-On (SSO) Services
Major cloud service providers offer dedicated Single Sign-On management suites that centralize identity assignment across multi-account, multi-subscription organizations: +-----------------------------------------------------------------------------------------+
- | ENTERPRISE CLOUD SSO ARCHITECTURE |
- | |
- | [Corporate Active Directory / Okta / Entra ID] (External Authoritative IdP) |
- | | |
- | SAML 2.0 / OIDC Federation Trust |
- | v |
- | [AWS IAM IDENTITY CENTER / AZURE ENTRA] |
- | | |
- | +-----------------------------+-----------------------------+ |
- | | | | |
- | v v v |
- | [AWS Account A] [AWS Account B] [AWS Account C] |
- | (Prod Infrastructure) (Staging Workloads) (Security & SIEM Logs) |
- | Role: Admin (2-Hr TTL) Role: Developer (4-Hr TTL) Role: SecurityAuditor (8-Hr) |
- +-----------------------------------------------------------------------------------------+
AWS IAM Identity Center (formerly AWS SSO): Centralizes access across multiple AWS accounts within an AWS Organization. It connects to corporate IdPs via SAML 2.0 or SCIM (System for Cross-domain Identity Management) and assigns Permission Sets that define IAM roles inside target member accounts.
Microsoft Entra ID (formerly Azure AD): Microsoft's multi-tenant cloud-based directory and identity service. It handles native SSO across Azure resources, Microsoft 365, and thousands of pre-integrated SaaS applications.
Google Cloud Identity: Identity as a Service (IDaaS) that provisions and manages users and groups centrally for Google Cloud Platform (GCP) and Google Workspace.
3. Hybrid Directory Synchronization Models
Organizations transitioning from on-premises Active Directory Domain Services (AD DS) to Microsoft Entra ID deploy Microsoft Entra Connect (formerly Azure AD Connect) using one of three architectural synchronization modes: +-----------------------------------------------------------------------------------------+
- | HYBRID DIRECTORY SYNCHRONIZATION COMPARISON |
- | |
- | 1. PASSWORD HASH SYNC (PHS) |
- | On-Prem AD ===(Hash of NT Hash Sync)===> Microsoft Entra ID (Cloud Auth) |
- | * Resilience: High (Works if on-prem WAN is completely down) |
- | |
- | 2. PASS-THROUGH AUTHENTICATION (PTA) |
- | Cloud Login ===(Real-Time Agent Query)===> On-Prem Domain Controller |
- | * Compliance: Passwords never stored in cloud; requires continuous on-prem uptime |
- | |
- | 3. ACTIVE DIRECTORY FEDERATION SERVICES (ADFS) |
- | Cloud Login ===(Browser Redirect)===> On-Prem ADFS Farm (SAML Token Issuance) |
- | * Infrastructure: Complex on-prem server farm; supports smart cards & custom claims|
- +-----------------------------------------------------------------------------------------+
Directory Synchronization Models Detailed:
Password Hash Synchronization (PHS):
How it Works: Entra Connect extracts a hash of the user's password hash from on-premises Active Directory (applying a 1000-iteration SHA-256 calculation over the MD4-based NT hash) and synchronizes it to Entra ID.
Benefits: Maximum resilience. If the on-premises corporate network or WAN connection experiences an outage, users can still authenticate to cloud applications seamlessly. Enables compromised credential monitoring (detecting dark-web leaks).
Pass-Through Authentication (PTA):
How it Works: When a user signs in, Entra ID places the authentication request in an encrypted queue. Lightweight on-premises software agents pull the request, validate credentials against local Domain Controllers, and return the result.
Benefits: Passwords (and their hashes) never reside in the cloud. User account lockouts and password policies enforced instantly in on-premises AD.
Active Directory Federation Services (ADFS):
How it Works: Complete federated identity infrastructure using on-premises federated servers and Web Application Proxies (WAPs). Cloud logins redirect users to the on-premises ADFS portal to generate a SAML token.
Considerations: Requires high-availability on-premises infrastructure. If the on-premises ADFS farm fails, all cloud logins fail immediately.
Synchronization Comparison Matrix
- Dimension Password Hash Sync (PHS) Pass-Through Auth (PTA) ADFS Federation
- Password Storage in Cloud Hash of a Hash None None
- Cloud Login During WAN Outage Yes (Fully Resilient) No (Fails) No (Fails)
- On-Prem Server Footprint Minimal (Sync Agent) Low (Lightweight Agents) High (ADFS Farm + WAP Proxies)
- Real-time On-Prem Lockout Delayed (Sync Interval) Immediate Immediate
- Smartcard / X.509 Auth Requires Entra CBA Requires Entra CBA Native ADFS Support
- 4. Cross-Account Access & STS AssumeRole Workflows
The Security Token Service (STS) is a foundational cloud web service that generates temporary, expiring security credentials comprising three elements:
An AccessKeyId (starts with ASIA... in AWS, identifying temporary credentials).
A SecretAccessKey .
A SessionToken (cryptographic token verifying authentication context and expiration). +-----------------------------------------------------------------------------------------+
- | CROSS-ACCOUNT STS ASSUME ROLE WORKFLOW |
- | |
- | ACCOUNT A (Identity Account) ACCOUNT B (Resource / Prod Account) |
- | +--------------------------+ +----------------------------------+ |
- | | User: Alice | | IAM Role: 'ProductionOperator' | |
- | | Invokes: | | Trust Policy: Principal=AccountA | |
- | | sts:AssumeRole(RoleARN) | | Permissions: EC2/RDS Full Control| |
- | +--------------------------+ +----------------------------------+ |
- | | ^ |
- | v | |
- | [Cloud STS Service] ======(Evaluates Trust Policy)=============+ |
- | | |
- | +======(Returns Temporary STS Token: 1-Hour Expiration)=====> Alice |
- | | |
- | Alice uses temporary STS credentials to manage resources in Account B ===+ |
- +-----------------------------------------------------------------------------------------+
Core STS APIs:
AssumeRole : Used for cross-account delegation between trusted accounts. Account B's role defines a Trust Policy (AssumeRolePolicyDocument) designating Account A as an authorized principal.
AssumeRoleWithSAML : Consumes a signed SAML 2.0 assertion from an enterprise IdP and exchanges it for temporary cloud credentials mapped to an IAM role.
AssumeRoleWithWebIdentity : Consumes an OIDC JSON Web Token from identity providers like GitHub Actions, Google, or Kubernetes Service Accounts to grant temporary cloud permissions without storing static cloud keys in CI/CD pipelines.
5. CompTIA Cloud+ Exam Traps & Real-World Pitfalls
Caution
Exam Trap: The Confused Deputy Problem and External ID When delegating cross-account access to a third-party SaaS vendor, an attacker might trick the vendor into using their cross-account role to access another customer's resources. To prevent this Confused Deputy attack, always require an ExternalId condition string in the role's trust policy that the vendor must pass during sts:AssumeRole .
Warning
Exam Trap: Static CI/CD API Keys vs OIDC Federation Never store static IAM access keys ( AKIA... ) in CI/CD pipeline repository secrets (e.g., GitHub Secrets). Instead, configure an OIDC identity provider in the cloud and use AssumeRoleWithWebIdentity to exchange short-lived OIDC tokens for temporary STS session credentials.