generated from coulomb/repo-seed
48 lines
1.4 KiB
Markdown
48 lines
1.4 KiB
Markdown
# 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.
|