Fine-Grained Authorization Models for CDN Resource Access Control

Traditional role-based access control breaks down when CDN infrastructure needs to authorize access at the individual resource level. A user with the “viewer” role should see their team's documents but not a competitor's product roadmap, even though both are cached on the same edge server. Fine-grained authorization (FGA) solves this by modeling access as relationships between specific users and specific resources — an approach pioneered by Google's Zanzibar system and now essential for CDN platforms that serve multi-tenant content with per-object access control requirements. For engineers building CDN security architectures, understanding FGA is the path to authorization decisions that are both precise and fast enough for edge-scale request processing.

Why Role-Based Access Control Fails at CDN Scale

RBAC assigns permissions to roles, and roles to users. A user with the “editor” role can edit all resources that editors are permitted to edit. This model works when permissions are coarse: admin vs. viewer, internal vs. external. It fails when the permission model requires per-object distinctions.

Consider a CDN serving a document collaboration platform. User Alice should view documents in Project Alpha and edit documents in Project Beta. User Bob should view documents in both projects but edit nothing. In RBAC, you would need roles like “project-alpha-viewer”, “project-beta-editor”, and so on — a role for every project-permission combination. With thousands of projects and millions of documents, RBAC produces a role explosion that is impossible to manage and slow to evaluate at CDN edge latency requirements.

FGA replaces role explosion with relationship tuples: (user:alice, editor, project:beta). The relationship is between a specific user and a specific object, and the CDN edge function evaluates whether the tuple (or a chain of tuples through group memberships and parent relationships) grants the requested access. The evaluation is a graph traversal, not a role lookup, and scales to billions of relationships with sub-10ms latency.

The Zanzibar Model: Relationship Tuples for CDN Resources

Google's Zanzibar paper introduced the relationship tuple model that forms the foundation of modern FGA systems. A relationship tuple has three components:

• User: The entity requesting access. Can be a specific user (user:alice), a group (group:engineering#member), or a wildcard (user:*).
• Relation: The type of relationship (viewer, editor, owner, parent).
• Object: The resource being accessed (document:readme, folder:/videos, endpoint:/api/users).

For CDN resources, objects map to content paths, cache keys, API endpoints, or streaming segment identifiers. The CDN edge server performs a check operation: “Does user:alice have the viewer relation on object:video/episode-3?” The FGA service traverses the relationship graph — checking direct tuples, group memberships, and inherited relationships through parent objects — and returns a boolean decision.

Authorization Model Design for CDN Resources

The authorization model defines the types of objects, relations, and the rules for how relations propagate. For CDN infrastructure, the model typically includes these object types:

Content Objects

Content objects represent the resources served through the CDN. A folder type has viewer and editor relations, with viewer access inherited from parent folders. A document type inherits access from its parent folder. A stream type has subscriber and owner relations for video delivery access control.

// Authorization model for CDN content
type folder
  relations
    define viewer: [user, group#member] or viewer from parent
    define editor: [user, group#member] or editor from parent
    define parent: [folder]

type document
  relations
    define viewer: viewer from parent
    define editor: editor from parent
    define parent: [folder]

type stream
  relations
    define subscriber: [user, group#member]
    define owner: [user]

API Endpoint Objects

For CDN-proxied API services, endpoint objects control access to specific API routes. An endpoint type has caller and admin relations, with the caller relation often inherited from a service group. This enables per-endpoint access control at the CDN API gateway layer without hardcoding permissions in the gateway configuration.

Cache Namespace Objects

For multi-tenant CDN platforms, cache namespace objects control which tenants can access which cache partitions. A namespace type has reader and writer relations, ensuring that cache operations (purge, warm, read) are scoped to the tenant's own namespace. This prevents cross-tenant cache poisoning or unauthorized cache invalidation.

FGA Check API Integration at CDN Edge

The check API is the primary interface between CDN edge servers and the FGA service. For every authenticated request, the edge server extracts the user identity from the JWT or session, maps the request path to an FGA object, determines the required relation based on the HTTP method, and calls the check API.

Mapping HTTP Methods to Relations

A common mapping for CDN-proxied content:

• GET, HEAD → viewer relation
• PUT, POST, PATCH → editor relation
• DELETE → owner relation
• Cache purge operations → admin relation

The edge worker performs the check before forwarding the request to the origin. If the check returns deny, the edge server returns a 403 response immediately, never touching the origin. This offloads authorization from the backend application to the CDN edge, reducing origin load and centralizing access control logic.

Performance Optimization for Edge Authorization

FGA check latency directly impacts CDN performance metrics. A 50ms authorization check on every request is unacceptable for edge-served content that targets sub-100ms total response times. Three optimization strategies bring FGA checks within CDN latency budgets.

Edge-Local Check Caching

The most effective optimization is caching check results at the CDN edge. The cache key is the tuple (user, relation, object), and the cached result is the boolean decision with a TTL of 10–30 seconds. This means the first request for a user-resource pair incurs the full FGA check latency, but subsequent requests within the TTL window are served from the edge cache.

The TTL must balance freshness against performance. A 30-second TTL means a revoked permission takes up to 30 seconds to take effect — acceptable for most content access, but potentially too long for sensitive operations. CDN architectures can use different TTLs for different relation types: longer TTLs for viewer access (low risk if stale) and shorter TTLs for editor and admin access (higher risk).

Pre-computed Authorization at Edge KV

For content that has predictable access patterns, the FGA service can pre-compute authorization decisions and push them to edge KV storage. When a user logs in or their permissions change, the FGA service evaluates all relevant check queries and writes the results to edge KV. The edge worker reads authorization decisions from KV instead of calling the check API, achieving sub-millisecond authorization latency.

This approach works well for subscription-based streaming platforms where a user's content access is determined at subscription time and changes infrequently. The FGA service pushes the user's authorized content catalog to edge KV when their subscription changes, and the CDN edge checks KV for every content request.

Inline Authorization Engine at Edge

For CDN platforms with simple authorization models, a lightweight FGA evaluation engine can run directly in the edge worker. The authorization model and a subset of relationship tuples relevant to the current PoP are loaded into edge worker memory. Check evaluations happen in-process without any network calls, achieving microsecond-level authorization latency.

This approach is practical when the number of relationships per PoP is manageable (under 100,000 tuples) and the authorization model does not require complex graph traversals. The relationship data is synchronized from the central FGA service to each PoP on a configurable interval, with eventual consistency being acceptable for the authorization use case.

Namespace Isolation for Multi-Tenant CDN

Multi-tenant CDN platforms where multiple organizations share the same CDN infrastructure require strict isolation between tenant authorization data. Without namespace isolation, a malicious tenant could potentially create relationship tuples granting themselves access to another tenant's resources.

FGA namespace isolation operates at the store level. Each tenant gets an independent FGA store with its own authorization model, relationship tuples, and check API endpoint. The CDN edge server determines the tenant from the request (typically from the hostname, an API key, or a JWT claim) and routes the check request to the tenant's FGA store.

The edge worker enforces the mapping between request identity and FGA store at the authentication layer, before any authorization check occurs. A request authenticated as tenant A can never trigger a check against tenant B's FGA store. This enforcement happens at the CDN edge, not at the FGA service, because the FGA service treats store IDs as opaque identifiers and does not perform tenant validation.

Relationship Tuple Lifecycle at CDN Scale

Relationship tuples are created, modified, and deleted as users join teams, content is shared, and permissions change. The lifecycle of tuples has direct implications for CDN edge authorization freshness.

Write Propagation to Edge

When a new relationship tuple is written (e.g., user:alice is granted viewer access to folder:/videos/premium), the change must propagate to CDN edge servers. The propagation happens through multiple channels:

• Cache invalidation: The FGA service publishes a change event. Edge servers that have cached check results for the affected user-object pair invalidate those cache entries. New requests trigger fresh check calls that reflect the updated relationship.
• KV update: For pre-computed authorization, the FGA service pushes updated decisions to edge KV. The edge worker reads the updated decision on the next request.
• In-memory refresh: For inline authorization engines, the edge worker's relationship data is refreshed on the next synchronization cycle.

The propagation delay determines how long a newly granted permission takes to become effective across all CDN PoPs. Typical propagation times range from sub-second (cache invalidation via pub/sub) to 30 seconds (edge KV eventual consistency) to 5 minutes (in-memory batch refresh). CDN architectures choose the propagation method based on the freshness requirements of the access control use case.

Relationship Tuple Garbage Collection

Deleted relationships must be cleaned up from all CDN edge caches and KV stores. A stale cached “allow” decision for a deleted relationship is a security vulnerability — the user retains access to a resource they should no longer see. CDN architectures address this by setting short TTLs on cached authorization decisions and by implementing explicit cache purge operations that the FGA service triggers when high-sensitivity relationships are deleted.

For compliance-sensitive CDN deployments, relationship deletion must be verifiable. The FGA service logs the deletion event, the CDN edge confirms cache invalidation, and the system provides an audit trail showing the maximum time between deletion and enforcement across all PoPs. This audit trail satisfies regulatory requirements for demonstrating that access revocation is effective and timely.

FGA for CDN Streaming Content Protection

Video streaming through CDN infrastructure presents unique FGA challenges because content is delivered as sequences of segments, each requiring authorization. A streaming session may generate thousands of segment requests over its lifetime, and each segment must be authorized to prevent unauthorized access to premium content.

The FGA approach for streaming uses a session-based authorization model. When a user initiates a stream, the edge server performs a single FGA check against the stream object. If authorized, the edge creates a streaming session with a session token. Subsequent segment requests present the session token, and the edge validates the session without performing additional FGA checks. The session has a bounded lifetime (typically 4–8 hours), after which a new FGA check is required to continue streaming.

This session-based model reduces FGA check volume by 99.9% compared to per-segment authorization while maintaining effective access control. Session revocation is handled by invalidating the session in edge KV when the user's subscription changes or when a rate limiting threshold is exceeded.

Observability and Debugging FGA at CDN Edge

FGA authorization failures at CDN edge servers are difficult to debug because the failure could originate at any point in the relationship graph traversal. The user might lack a direct relationship, a group membership might have expired, or a parent relationship might be missing.

CDN monitoring systems should capture FGA check metrics broken down by decision (allow/deny), relation type, object type, and PoP. A spike in deny decisions for a specific object type might indicate a broken relationship propagation rather than an actual access violation. The FGA service's list-objects API can help debug denials by showing which objects a user does have access to, revealing whether the issue is a missing relationship or a misconfigured authorization model.

Edge workers should log the full check context (user, relation, object, decision, latency, cache hit/miss) for every authorization decision. These logs feed into CDN log analysis pipelines that can correlate authorization patterns with content access patterns, identify permission drift, and detect anomalous access attempts across the CDN fleet.