coulomb/net-kingdom
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Implement NK-WP-0012 IAM profile specification

Browse Source
This commit is contained in:
Bernd Worsch
2026-05-22 14:35:31 +02:00
parent 48cd174b00
commit c3f721397a
12 changed files with 1649 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/platform-identity-security-architecture.md
View File

@@ -124,6 +124,12 @@ key-cape is the lightweight profile implementation. Keycloak is the
expanded-mode profile implementation. privacyIDEA provides MFA/token
capabilities where the deployment mode uses it.
The canonical profile is NetKingdom IAM Profile v0.2
(`canon/standards/iam-profile_v0.2.md`). It requires explicit `tenant`,
`principal_type`, `groups`, `roles`, `scope`/`scp`, and `assurance`
claims so flex-auth receives normalized identity input regardless of
whether key-cape or Keycloak issued the token.
The choice between lightweight and expanded mode is **capability-driven,
not scale-driven**. key-cape comfortably serves large internal user
populations; expanded-mode Keycloak is introduced when a *capability* is
@@ -333,9 +339,12 @@ Required implications:
- Policy packages must distinguish `tenant:platform` policy from
tenant-local packages such as `tenant:coulomb`.
- Decision envelopes must carry subject, issuer, audience, tenant,
protected-system id, resource, action, requested TTL where relevant,
assurance evidence, obligations, deny reasons, and audit correlation
ids.
principal type, groups, roles, scopes, protected-system id, resource,
action, requested TTL where relevant, assurance evidence, obligations,
deny reasons, and audit correlation ids. Subject, issuer, audience,
tenant, principal type, groups, roles, scopes, and assurance come from
the IAM Profile v0.2 token contract rather than provider-specific
session state.
- Topaz is a delegated PDP runtime behind flex-auth. It must not become
the canonical policy model, identity provider, or platform control
plane.
@@ -428,7 +437,7 @@ an explicit check:
| Area | Readiness check |
| --- | --- |
| MFA and identity | key-cape or Keycloak issues IAM Profile-compatible tokens; privacyIDEA or the selected MFA provider enforces required assurance for privileged actions |
| MFA and identity | key-cape or Keycloak issues IAM Profile v0.2-compatible tokens and passes `tools/iam-profile-conformance/`; privacyIDEA or the selected MFA provider enforces required assurance for privileged actions |
| Bootstrap and recovery | age/SOPS material, emergency bundle, and break-glass credentials are present, tested, and separated from tenant administration |
| OpenBao runtime secrets | OpenBao is initialized, unsealed or auto-unsealed by the approved mechanism, backed up, audited, and using scoped auth methods and mounts |
| Secret rotation | service, database, OpenBao-issued, and break-glass rotation paths have documented blast radius and verification steps |
@@ -449,9 +458,7 @@ an explicit check:
or via CSI-mounted secrets?
- Which tenant metadata is required before a service can register
resources with flex-auth?
- When does the platform switch from key-cape lightweight mode to
Keycloak expanded mode? (Answered as capability-driven — see Capability
Progression, tier C5. The remaining open part is the precise per-tenant
trigger and dual-issuer coexistence rule, owned by NK-WP-0011-T1.)
- What precise per-tenant trigger and dual-issuer coexistence rule should
NK-WP-0011-T1 use for Keycloak expanded mode?
- Does Topaz run centrally for the platform, per tenant, or per service
for the first production deployment?