PATTERN Cited by 1 source
Identity exchange across identity domains¶
Problem¶
Modern data platforms span multiple identity domains (e.g., an internal application identity system and AWS IAM). A single workflow execution may need to authenticate against internal table ACLs, internal authorization policies, and AWS IAM policies — all in one run. Maintaining separate credentials per domain is fragile and creates permission drift.
Solution¶
Provision a composite identity per logical project with credentials in each domain, linked by a cryptographic exchange mechanism:
- Each project gets a primary identity (e.g., Netflix application identity).
- Each project optionally gets a secondary identity in external domains (e.g., AWS IAM role).
- A secure token-exchange protocol allows converting between domains at runtime — the IAM role can be exchanged for the primary identity cryptographically.
Consequences¶
- Positive: Single logical owner across identity domains; workflows can traverse authorization boundaries without human intervention; auditability is unified.
- Negative: Exchange mechanism is a security-critical component; compromise of the exchange path compromises both domains; requires careful trust-boundary design.
Canonical implementation¶
Netflix Data Projects provision both a Netflix application identity and an AWS IAM role per project. The IAM role supports specialized AWS compute (Spark on EMR) and can be exchanged for the Netflix identity in a cryptographically secure way (Source: sources/2026-06-19-netflix-data-projects-managing-data-assets-at-netflix-scale).