diff --git a/INTENT.md b/INTENT.md index 31b839a..af1a40c 100644 --- a/INTENT.md +++ b/INTENT.md @@ -57,6 +57,10 @@ This means: * Security is **continuously adapting**, not periodically configured * Identity, access, and secrets form a **coherent control loop** * The system can **start small (bootstrap)** and grow into **enterprise-grade security** +* You **select the capabilities you need**, and NetKingdom **places and + orchestrates** the right components to **turn-key readiness** — bringing + an IT landscape up safely and iteratively, like building a house to + handover condition * Security decisions become **observable, testable, and evolvable** --- @@ -97,18 +101,24 @@ No hidden black boxes at the foundation. --- -### 4. Progressive Expansion +### 4. Progressive, Capability-Driven Expansion -Security evolves in stages: +Security evolves by **adding capabilities**, not by rebuilding. The path +runs from bootstrap identity, through lightweight SSO and 2FA, runtime +secrets and fine-grained authorization, up to enterprise federation SSO — +but each step is taken **because a capability is needed, never because of +user count**. Footprint and cost follow the capability choice; they do not +drive it. -1. **Bootstrap (local identity)** -2. **Lightweight mode** -3. **Expanded enterprise mode** +Each tier must: -Each stage must: +* **be usable on its own** — you get value at every tier, not only at the top +* **transition without structural breaks** — because every tier targets + the same IAM Profile contract, adding 2FA, secrets, authorization, or + federation *extends* the system rather than replacing it -* be usable on its own -* smoothly transition into the next +> The concrete capability ladder (C0–C6) lives in +> `docs/platform-identity-security-architecture.md` → *Capability Progression*. --- @@ -141,9 +151,17 @@ NetKingdom is: * a **security control core** * a **reference architecture** * a **bootstrap path from zero → production-grade security** +* a **capability-selectable, turn-key orchestrator** for identity, + authentication, and authorization — it places the right components and + brings them to ready-to-run state, then grows tier by tier * a **contract layer for identity and trust** * a **foundation for agent-aware security systems** +This is the larger ambition: an **IT-security framework that builds IT +landscapes safely and iteratively from scratch** — you choose how far up +the capability ladder you need to go, and the system gets you there +without structural breaks. + --- ## What This Is Not diff --git a/docs/platform-identity-security-architecture.md b/docs/platform-identity-security-architecture.md index 8f92984..83c866a 100644 --- a/docs/platform-identity-security-architecture.md +++ b/docs/platform-identity-security-architecture.md @@ -124,6 +124,17 @@ 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 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 +required that the lightweight stack does not provide — chiefly inbound +enterprise federation and SAML brokering (Entra ID, Active Directory, +generic SAML IdPs), complex multi-realm topologies, or delegated admin. +A deployment climbs to expanded mode because it needs that capability, +not because it has more users. The lower resource and operational +footprint of the lightweight stack is a consequence of this rule, not the +trigger for it. See **Capability Progression** below. + Identity answers: who is this actor, how was the actor authenticated, what coarse claims are asserted, and what assurance evidence exists? @@ -368,6 +379,48 @@ receive a scoped authorization decision, obtain only the allowed secret or short-lived credential, enforce the decision locally, and produce an auditable record without receiving platform-root authority. +## Capability Progression (Start Small → Enterprise) + +NetKingdom is designed so an IT landscape can be brought up from nothing +and hardened **one capability at a time**, with no structural rework when +the next capability is added. Every tier is usable on its own and every +tier issues or consumes the same NetKingdom IAM Profile, so adding a +capability extends the system rather than replacing it. + +The progression is capability-keyed: you climb a tier when you need the +capability it adds, never because of user count. + +| Tier | Capability added | Components added | You move here when… | +| --- | --- | --- | --- | +| **C0 — Bootstrap identity** | A local OIDC issuer + secret bootstrap so things can start safely before the platform exists | local-identity (NK-WP-0002), SOPS/age + agent bootstrap (NK-WP-0004/0005) | you have nothing yet and need dev/test/sandbox identity | +| **C1 — Lightweight SSO** | Single-factor OIDC SSO over an internal directory | key-cape: Authelia + LLDAP | you want real SSO for internal users/services | +| **C2a — 2FA (light)** | Second factor without a new heavy service | Authelia built-in TOTP / WebAuthn | you need 2FA but not enterprise token lifecycle | +| **C2b — Token authority** | Hardware tokens, many token types, self-service enrollment, token lifecycle | privacyIDEA | you need an enterprise-grade MFA/token authority | +| **C3 — Runtime secrets** | Dynamic, scoped, leased, audited secrets beyond bootstrap | OpenBao (NK-WP-0006) | workloads need runtime secrets, not just bootstrap material | +| **C4 — Fine-grained authZ** | Policy-as-code decisions beyond coarse SSO claims | flex-auth + Topaz PDP (ADR-0006) | identity alone can no longer answer "may this actor do this?" | +| **C5 — Enterprise federation** | Inbound Entra ID / AD / SAML brokering, multi-tenant realms | expanded-mode Keycloak (NK-WP-0011) | identities originate in an external enterprise IdP | +| **C6 — Self-optimizing** | Audit feedback loops, drift surfacing, continuous adaptation | central audit sink + kaizen loops | the platform should improve and verify itself continuously | + +Two properties make this safe rather than just sequential: + +- **Usable at every tier.** C1 is a working SSO platform; you are never + forced to reach C5 to get value. +- **No structural breaks.** Because every tier targets the IAM Profile + contract, 2FA (C2), runtime secrets (C3), fine-grained authorization + (C4), and federation (C5) are *additive*. Applications keep targeting + the same Profile; the implementation behind it grows. + +2FA illustrates the principle precisely: if you do not need a second +factor, C2 is simply absent — the C1 stack runs without privacyIDEA. When +you do, C2a (Authelia's built-in TOTP/WebAuthn) is the light option and +C2b (privacyIDEA) is the enterprise token-authority option. Neither +requires re-architecting C1. + +The intent is turn-key: NetKingdom selects, places, and orchestrates the +components for the chosen tier set so the landscape reaches ready-to-run +state — like building a house to handover condition — and can be extended +to the next tier later without demolition. + ## Production Readiness Checks Before the security platform is production-ready, each trust state needs @@ -397,6 +450,8 @@ an explicit check: - 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? + 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.) - Does Topaz run centrally for the platform, per tenant, or per service for the first production deployment?