# Pattern: Central Identity Provider

Status: seed
Readiness target: RL3 production
Primary owners: NetKingdom, key-cape, Keycloak
Genesis family: Identity and access

## Problem

Services drift into local user stores and inconsistent login behavior
when there is no shared identity source.

## Context

Use this pattern for platform services, admin tools, product
applications, and operational interfaces that need interactive user
login or identity claims.

## Forces

- Product teams need a simple integration point.
- Platform operators need lifecycle, MFA, and audit consistency.
- Lightweight local identity and expanded Keycloak deployments need to
  share a stable profile contract.
- Tenant users and platform operators must remain distinguishable.

## Solution

Route interactive authentication through a central IdP and expose a
stable NetKingdom IAM Profile to consumers. The implementation may be
lightweight key-cape mode or expanded Keycloak mode, but applications
consume the same issuer, audience, subject, tenant, role, and assurance
shape.

## Verification

- Applications reject tokens from unknown issuers or audiences.
- Privileged flows require MFA or equivalent assurance evidence.
- User disablement removes access across integrated services.
- Audit events identify user, tenant, issuer, and client.

## Related Patterns

- Identity Broker.
- Tenant Membership Boundary.
- Human/Agent Identity Split.
- Delegated Authorization.