The layer model is now published as net-kingdom/canon/standards/security-layer-model_v0.1.md (proposed) and ratified by gate-house GH-DEC-2026-001. The note previously said the standard was not yet written. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
111 lines
4.4 KiB
Markdown
111 lines
4.4 KiB
Markdown
# INTENT
|
|
|
|
> **NetKingdom layering review — 2026-08-28.** This repository's role was reviewed
|
|
> against the NetKingdom IT-security layer model: **Taxonomy → Tooling → Engines →
|
|
> Staff**, layered by determinism and by the kind of artifact each layer produces.
|
|
> Findings and the argument behind them:
|
|
> `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`.
|
|
> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed),
|
|
> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001.
|
|
>
|
|
> The layer rule that binds every repository: **Staff never touches tooling
|
|
> directly. It acts only through engine APIs.**
|
|
>
|
|
> **This repository is Tooling — deterministic infrastructure and state.** State the layer: key-cape packages the third-party identity tooling (authelia, lldap, privacy-idea) behind a versioned IAM profile. It owns authentication and identity claims only. Because "auth" is ambiguous across the estate, this INTENT should say explicitly that key-cape is **not** an authorization decision point — that is access-engine's, and it stays the only one.
|
|
>
|
|
> *This note records what should change. The body below is not yet adapted.*
|
|
|
|
## Purpose
|
|
|
|
This repository exists to provide a **lightweight, profile-conformant identity and access management (IAM) system**.
|
|
|
|
It ensures that applications can rely on a **stable, versioned authentication contract** independent of the underlying IAM implementation.
|
|
|
|
---
|
|
|
|
## Primary Utility
|
|
|
|
The repository provides an implementation of a **versioned IAM profile** that:
|
|
|
|
* Delivers OIDC/PKCE-based authentication with strong security constraints
|
|
* Normalizes identity data across heterogeneous backend systems
|
|
* Enforces strict adherence to the defined IAM contract
|
|
* Enables seamless migration between lightweight and expanded IAM modes
|
|
|
|
It transforms IAM from a system dependency into a **replaceable, contract-driven capability**.
|
|
|
|
---
|
|
|
|
## Intended Users
|
|
|
|
* Application developers integrating against the IAM profile
|
|
* Infrastructure operators (`adm`) deploying IAM in constrained environments
|
|
* Automation systems (`atm`) managing identity, migration, and validation workflows
|
|
* LLM agents (`agt`) interacting with authenticated services
|
|
|
|
---
|
|
|
|
## Strategic Role in the System
|
|
|
|
This repository serves as the **lightweight IAM layer**:
|
|
|
|
* It provides a **resource-efficient implementation** of the IAM profile for environments with limited resources
|
|
* It anchors IAM around a **profile contract rather than a specific implementation**
|
|
* It enables a **two-mode architecture**:
|
|
|
|
* Lightweight mode (this implementation)
|
|
* Expanded mode (a heavier, full-featured implementation)
|
|
|
|
The profile ensures that both modes are **interchangeable without application changes**.
|
|
|
|
---
|
|
|
|
## Strategic Boundaries
|
|
|
|
This repository is **not** intended to:
|
|
|
|
* Become a full-featured, general-purpose IAM platform
|
|
* Extend beyond the defined IAM profile
|
|
* Support features that weaken security guarantees (e.g., implicit flow, wildcard redirects)
|
|
* Replace or wrap the heavier expanded-mode implementation
|
|
|
|
Its responsibility is limited to **strict, secure, and transparent profile implementation**.
|
|
|
|
---
|
|
|
|
## Design Principles
|
|
|
|
* **Contract over implementation**
|
|
Applications depend on the IAM profile, not on KeyCape internals
|
|
|
|
* **Security through constraint**
|
|
Only explicitly allowed features are supported; unsafe patterns are rejected
|
|
|
|
* **Explicitness over convenience**
|
|
Unsupported features must fail clearly and predictably
|
|
|
|
* **Replaceability by design**
|
|
The system must be swappable with a heavier profile implementation without breaking integrations
|
|
|
|
* **Canonical identity model**
|
|
Identity data must be normalized and consistent across all backends
|
|
|
|
---
|
|
|
|
## Maturity Target
|
|
|
|
A mature version of this repository should:
|
|
|
|
* Fully implement and enforce the **IAM profile** with zero ambiguity
|
|
* Provide **complete migration pathways** between lightweight and expanded modes
|
|
* Offer **deterministic and testable behavior** across all supported scenarios
|
|
* Act as a **reference implementation** of the IAM profile
|
|
* Enable IAM deployments that are **minimal, secure, and operationally efficient**
|
|
|
|
---
|
|
|
|
## Stability Note
|
|
|
|
Changes to this file represent a **deliberate shift in the IAM contract, scope, or architectural role** of this repository.
|
|
|
|
Such changes must be made with explicit intent, as they directly affect all dependent applications.
|