SSO Federation for Multi-Tenant CDN Architectures

Enterprise CDN deployments serve content for dozens or hundreds of tenant organizations, each with its own identity provider, security policies, and user base. When Acme Corp's employees access the CDN-delivered dashboard through their Okta instance while Globex Industries' team authenticates via Azure AD, the CDN edge must seamlessly handle both — validating tokens from different identity providers, routing users to the correct IdP, and maintaining strict isolation between tenants' authentication contexts. SSO federation at the CDN edge layer solves this by establishing trust relationships with multiple identity providers simultaneously, enabling the edge to authenticate users from any tenant without each application needing its own federation configuration.

How Does SSO Federation Work at the CDN Edge?

In a federated CDN architecture, the edge node acts as a federation gateway — a centralized point that brokers authentication between tenant users and their respective identity providers. Instead of each backend application maintaining its own SAML or OIDC integration, the edge handles the entire federation flow and passes verified identity information to the origin as standardized headers or tokens.

The flow begins when an unauthenticated user requests a protected resource. The edge checks for a valid session cookie or JWT bearer token. Finding none, it needs to determine which identity provider to use for this specific user. This is the Identity Provider Discovery problem — also called Home Realm Discovery (HRD) — and it's the first challenge unique to multi-tenant federation.

The discovery mechanism most commonly uses email domain mapping. The user enters their email at a tenant-neutral login prompt. The edge extracts the domain (e.g., acme.com), queries the tenant registry (cached in edge KV storage), and retrieves the corresponding IdP configuration: OIDC discovery URL, client ID, redirect URI, and authorized scopes. The edge then initiates the OAuth/OIDC authorization code flow, redirecting the user to their organization's identity provider.

After the user authenticates at their IdP, the callback returns to the edge with an authorization code. The edge exchanges the code for tokens, validates the ID token's signature against the IdP's JWKS endpoint (cached at the edge), extracts the user's identity claims, and creates an edge session. The session is stored in edge KV with the tenant context attached, and a secure session cookie is set for the user's domain.

How Do SAML and OIDC Federation Compare at the Edge?

CDN edge deployments must choose between SAML 2.0 and OpenID Connect as the federation protocol for each tenant. While many enterprise identity providers support both, the protocol choice affects edge processing performance, token size, and implementation complexity.

SAML assertions are XML documents ranging from 2KB to 10KB, signed with XML Digital Signatures (XMLDSig). Validating a SAML assertion at the edge requires XML parsing, canonicalization (converting XML to a canonical form before signature verification), and RSA or ECDSA signature validation. This process takes 5 to 15 milliseconds on edge hardware — significantly slower than JWT validation.

OIDC ID tokens are compact JWTs typically under 2KB. Validation requires base64 decoding, JSON parsing, and signature verification — a process that completes in under 1 millisecond using cached JWKS keys. OIDC also supports the PKCE extension for added security in browser-based flows, and the authorization code exchange happens server-side (edge-to-IdP) rather than through browser redirects, reducing the attack surface.

For multi-tenant CDN deployments, the edge federation gateway should support both protocols simultaneously. Many enterprise customers with legacy IdP infrastructure require SAML support, while newer deployments and B2C tenants prefer OIDC. The edge abstracts this difference by normalizing both assertion types into a common internal session format after validation. Backend applications receive the same standardized identity headers regardless of whether the user authenticated via SAML or OIDC, eliminating per-protocol logic at the application layer.

How Do You Implement Tenant Isolation in Federated CDN Authentication?

Tenant isolation is the critical security requirement in any multi-tenant system. In a federated CDN, isolation failures could allow users from Tenant A to access Tenant B's resources, or allow a compromised tenant IdP to generate tokens that grant access to other tenants' data. The edge must enforce isolation at every layer of the authentication and authorization stack.

At the IdP trust layer, each tenant's IdP configuration is stored as an isolated entry in the tenant registry. The registry maps each trusted issuer URL to exactly one tenant. When the edge validates a token, it extracts the iss (issuer) claim and verifies that the issuer is registered for the tenant associated with the requested resource. A token from Acme's Okta instance (iss: https://acme.okta.com) is valid only for resources owned by the Acme tenant. If an attacker somehow obtains a valid token from Acme's IdP and attempts to access Globex's resources, the edge rejects the request because the issuer does not match Globex's registered IdP.

// Tenant isolation check at the edge
function validateTenantAccess(token, requestedResource) {
  const tokenIssuer = token.claims.iss;
  const tokenTenant = tenantRegistry.getTenantByIssuer(tokenIssuer);
  const resourceTenant = tenantRegistry.getTenantByResource(
    requestedResource.hostname
  );

  if (!tokenTenant || !resourceTenant) {
    return { allowed: false, reason: "unknown_tenant" };
  }

  if (tokenTenant.id !== resourceTenant.id) {
    return { allowed: false, reason: "cross_tenant_access" };
  }

  // Additional per-tenant authorization checks
  const tenantPolicy = tenantRegistry.getPolicy(tokenTenant.id);
  if (!tenantPolicy.authorizeUser(token.claims, requestedResource)) {
    return { allowed: false, reason: "insufficient_permissions" };
  }

  return { allowed: true, tenant: tokenTenant };
}

At the cache layer, cache keys must include the tenant identifier. Without tenant-aware caching, an edge node could cache a response generated for Tenant A's user and serve it to Tenant B's user requesting the same URL path. The tenant ID is derived from the validated token, not from the request URL alone, preventing cache poisoning attacks where an attacker crafts requests with misleading URL patterns. Cache partitioning by tenant adds some cache fragmentation overhead but is non-negotiable for security.

At the origin routing layer, each tenant maps to specific origin servers. After authentication and authorization, the edge forwards the request to the tenant's designated origin with standardized identity headers (X-Tenant-ID, X-User-ID, X-User-Email, X-User-Groups). The origin trusts these headers because they are set by the edge after cryptographic token validation — the origin does not accept these headers from direct client requests. This is a core principle of zero-trust architecture: the edge authenticates, and the origin authorizes based on the verified identity.

How Do You Handle Cross-Domain Sessions in Multi-Tenant CDN Federation?

Multi-tenant CDN deployments often serve the same tenant's applications across multiple domains: app.acme.com, portal.acme.com, and api.acme.com. Users expect seamless SSO across these domains — authenticating once and accessing all applications without re-entering credentials. Browser cookie isolation rules make this challenging because cookies set for one domain are invisible to another.

For subdomains of the same parent domain, the edge sets session cookies on the parent domain with the Domain=.acme.com attribute. All subdomains under acme.com share the session cookie, and the edge validates it on any request to those subdomains. This is the simplest case and works reliably across all browsers.

For different domains (acme-portal.com and acme-dashboard.io), the edge implements a session hub pattern. A dedicated domain (e.g., auth.acme-hub.com) serves as the SSO hub. When a user authenticates on acme-portal.com, the edge establishes a session at the hub domain. When the user navigates to acme-dashboard.io, the edge detects no session cookie for that domain and redirects to the hub. The hub recognizes the existing session, generates a short-lived authorization code, and redirects back to acme-dashboard.io with the code. The edge exchanges the code for a domain-specific session cookie. The entire redirect chain completes in 2 to 3 round-trips (under 500 milliseconds).

This hub-based approach avoids dependency on third-party cookies, which have been deprecated or restricted by major browsers. The edge manages the redirect chain transparently — from the user's perspective, clicking a link to acme-dashboard.io loads the dashboard immediately with their identity intact.

What Are the Performance Optimization Strategies for Federated CDN Auth?

Federation flows add authentication latency to the initial user experience. While subsequent requests use cached sessions (sub-millisecond validation at the edge), the first authentication involves multiple redirects and external IdP communication. Optimizing this initial flow is critical for user satisfaction.

IdP metadata caching eliminates repeated fetches. The edge caches each tenant's OIDC discovery document (/.well-known/openid-configuration) and JWKS keys with aggressive TTLs (1 hour for discovery, 24 hours for JWKS with background refresh). This means the edge never fetches IdP metadata in the critical path of an authentication request — it is always pre-cached from background refreshes.

Token exchange optimization reduces round-trips. When the OIDC callback arrives at the edge, the code-for-token exchange requires an HTTP request from the edge to the IdP's token endpoint. The edge maintains persistent HTTP/2 connections to frequently used IdPs, eliminating TLS handshake and connection setup latency for this exchange. For high-volume tenants, the edge pre-warms these connections during idle periods.

Session replication across edge nodes ensures that a user authenticated at one PoP does not need to re-authenticate when their requests are routed to a different PoP. Edge sessions are stored in globally replicated KV storage with eventual consistency (propagation under 500 milliseconds). A user who authenticates at the US-East edge node can access resources from the EU-West node within seconds without re-authentication.

For monitoring, track federation-specific metrics: IdP response latency per tenant (identify slow IdPs that degrade user experience), token validation failure rates (detect IdP configuration issues or key rotation problems), cross-domain SSO redirect chain completion time, and session hit ratio (percentage of requests served from cached sessions vs. requiring fresh authentication). A healthy federation deployment shows session hit ratios above 95% and authentication flow completion times under 3 seconds.

Frequently Asked Questions