8.2 Identity Federation, SSO & Directory Integration

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):
  1. Header: Algorithm (alg: RS256) and token type (typ: JWT).
  2. Payload (Claims): Issuer (iss), Subject (sub), Audience (aud), Expiration (exp), Issued-At (iat), and custom claims (e.g., email, department).
  3. 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

---

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:

1. 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).
2. 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.
3. 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

---

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:

1. An AccessKeyId (starts with ASIA... in AWS, identifying temporary credentials).
2. A SecretAccessKey.
3. 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.