generated from coulomb/repo-seed
48 lines
1.4 KiB
Markdown
48 lines
1.4 KiB
Markdown
# Pattern: Identity Broker
|
|
|
|
Status: seed
|
|
Readiness target: RL3 production
|
|
Primary owners: NetKingdom, key-cape, Keycloak
|
|
Genesis family: Identity and access
|
|
|
|
## Problem
|
|
|
|
External, customer, or ecosystem identities cannot be trusted directly
|
|
by every product service without duplicating federation and mapping
|
|
logic.
|
|
|
|
## Context
|
|
|
|
Use this pattern when tenants bring their own IdP, when operators need
|
|
multiple upstream identity sources, or when the platform must normalize
|
|
federated identity into the IAM Profile.
|
|
|
|
## Forces
|
|
|
|
- Upstream IdPs have different claim shapes and assurance semantics.
|
|
- Tenant membership is not the same as global user identity.
|
|
- Product applications need stable claims.
|
|
- Federation errors can create cross-tenant or privilege confusion.
|
|
|
|
## Solution
|
|
|
|
Broker external identity through a controlled IAM layer that validates
|
|
upstream issuer trust, maps claims into the NetKingdom IAM Profile, and
|
|
records federation source, tenant membership, assurance, and lifecycle
|
|
state.
|
|
|
|
## Verification
|
|
|
|
- Each upstream IdP has explicit trust metadata and claim mappings.
|
|
- Tenant membership is resolved after federation, not assumed from raw
|
|
upstream claims.
|
|
- Assurance and MFA evidence are normalized for privileged flows.
|
|
- Federation failures fail closed with auditable reason codes.
|
|
|
|
## Related Patterns
|
|
|
|
- Central Identity Provider.
|
|
- Tenant Membership Boundary.
|
|
- Role Composition.
|
|
- Object-Level Authorization Check.
|