# 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.