Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0e715-b802-70f0-a8fa-590d9ee673a5
10 KiB
| id | type | title | domain | repo | status | flavor | owner | topic_slug | created | updated | related | state_hub_workstream_id | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HUB-WP-0012 | workplan | NetKingdom identity and tenant integration: platform-root first | infotech | hub-core | proposed | implementation | codex | infotech | 2026-09-28 | 2026-09-28 |
|
e61ce290-c5ec-516c-8589-ef9a55cf3aa3 |
NetKingdom integration, platform-root first
Outcome and boundaries
The existing platform-root login receives full Hub Core, extension and platform access, including Railiance, through verified NetKingdom identity and the owners' enforcement paths. Other human users are denied initially. Public exposure waits for access-control evidence and a separate approved rollout.
Architecture blueprint defines the contract and reviewed baseline. This is the single new integration workplan; existing retirement and rollout plans retain their tasks. Core Hub receives no new product feature work. This planning session does not implement or activate grants, enroll factors, deploy policies, expose services or retire State Hub.
Status is proposed because cross-owner policy, root identity binding and live acceptance are not yet reviewed. The user has selected the root-first scope; there is no need to reopen that product decision. Dependencies below are per-task sequencing, not a blanket wait for every related workplan to finish.
T01 — Freeze the integration contract and platform coverage matrix
id: HUB-WP-0012-T01
status: todo
priority: high
state_hub_task_id: "204f4fb0-e240-5558-8790-5985517b85e0"
Owner: hub-core; contract reviewers: NetKingdom, user-engine, tenant-engine, flex-auth and affected extension/platform owners. Review the blueprint and inventory every HTTP route, alias, MCP tool, embedded router and active platform service/management surface. Record audience, action/resource, actor/target tenant, enforcement point and test owner for each. Include Railiance Kubernetes, GitOps/deployments, SSH, observability and platform identity/secret administration. Confirm root's explicit cross-tenant administrative coverage and existing approval obligations. Set the versioned security-profile and migration contract.
Done when no published route/tool or active platform surface lacks a row and owner, contract reviewers' decisions are recorded, and M1 success/deny cases are executable specifications. Unknown/disputed rows remain visible blockers.
T02 — Bind platform-root identity, login, tenant and revocation
id: HUB-WP-0012-T02
status: todo
priority: high
state_hub_task_id: "9a955fbf-f289-51b7-9682-bbe471694595"
Depends on T01. Owners: NetKingdom/KeyCape, user-engine and tenant-engine;
hub-core owns consumption. Resolve the existing root account to (iss, sub)
without recording credentials. Establish its explicit platform entitlement,
map existing platform-operator vocabulary, register Hub clients/audiences and
exact redirects, and implement PKCE sessions and API token validation. No
username comparison or first-login promotion. Require the existing AAL2 floor
and accepted enrollment/recovery; do not assume proposed IAM v0.4 step-up works.
Fix measurable session/token/assurance lifetimes and revocation bounds; include
live authoritative tenant/account checks for privileged actions.
Done when attended root login succeeds privately, an ordinary account and a forged same-name account fail, MFA/recovery/logout/key rotation work, and suspension/grant withdrawal deny within the agreed bound. Record immutable identity references and sanitized receipts only. Reuse NK-WP-0042 if additional step-up implementation is actually required.
T03 — Deliver root policy and authenticated decision evaluation
id: HUB-WP-0012-T03
status: todo
priority: high
state_hub_task_id: "feea8f20-aad4-583b-958a-a8efeb9c133c"
Depends on T01; live acceptance also needs T02. flex-auth owns the protected system, complete action/resource grant and service deployment; platform owners own credential/signing-key delivery. Hub Core owns enforcement integration. Authenticate the calling workload separately from the end user, validate fact provenance, signed decision origin, request binding and obligations. Root gets all registered platform actions; non-root humans deny; callers get explicit workload grants only. Fail closed on unsigned/untrusted, stale, mismatched, unavailable or obligation-incomplete decisions. Prove audit durability and key rotation. No token/PDP credential reuse from another protected system.
Done when a private pinned deployment passes positive root decisions and the tampered-signature, wrong actor/action/resource/tenant, expired decision, untrusted caller and policy-outage matrix. Finished signing source work is not substituted for evidence of production custody and delivery.
T04 — Enforce the boundary across Hub Core and its clients
id: HUB-WP-0012-T04
status: todo
priority: high
state_hub_task_id: "15bc3cae-4575-56c9-afd2-e1e348109ca9"
Depends on T02/T03. Add the reusable verified actor/tenant context and local enforcement seam to all native ports, projections, compatibility routes/aliases, catalogs/docs, browser, MCP and embedded router paths. Minimal liveness and login mechanics are the only public exceptions. Bind messaging/event producer identity to the caller; prevent direct-Service bypass. Remove shared root credentials from normal clients and confine unavoidable migration keys to named private lanes. Add readiness checks for configured identity/policy dependencies. Root can administer every Hub Core function; an ordinary logged-in user cannot. Include revocation, concurrency, cache and audit-failure tests.
Done when the route/tool inventory is covered by automated allow/deny tests, private full-root browser/API/MCP journeys pass, and legacy callers have tested bounded migration/rollback paths without a public bypass.
T05 — Admit extensions and State Hub migration callers
id: HUB-WP-0012-T05
status: todo
priority: high
state_hub_task_id: "6d29854e-e894-5340-9e13-8866e80246f4"
Depends on T04. Publish the versioned extension security profile and harness. Use ops-hub as first extension, then all inventoried exposed extensions; activity-core, Repo Manager and inbox readers receive separate workload identities. Each extension enforces audience/action/tenant and authenticates delegation; no forwarding root tokens across audiences. Preserve domain/Fabric authority and explicit unsupported/deferred surfaces.
Done when root succeeds and anonymous/non-root/wrong-tenant/wrong-audience callers fail across extension boundaries; calls and audit retain actor plus workload identities. HUB-WP-0011-T02 consumes this contract, while its T01/T03 retain freshness and reader cutover. STATE-WP-0079 keeps each slice's writer, parity, retention and zero-traffic gates. This task does not claim retirement.
T06 — Prove full platform-root coverage, including Railiance (M1)
id: HUB-WP-0012-T06
status: todo
priority: high
state_hub_task_id: "97b0b242-e9a7-53cd-941f-a1822fcf93a5"
Depends on T04/T05 and the external owners for each T01 row. Integrate the same root identity/entitlement with all inventoried platform management surfaces. Use native owner paths for SSH certificates, Kubernetes/RBAC, GitOps, credentials and approvals; Hub Core is not an unrestricted execution proxy. Keep caller and human attribution distinct and preserve existing confirmation and approval obligations. Test allowed administration with reversible or isolated operations and independently verify denied non-root attempts.
M1 is accepted only when every coverage row has an attended/live receipt, including full Hub Core access and Railiance administration, revocation and audit. A navigation link or Hub Core token alone is not evidence of access to another service. Any missing backend integration keeps M1 open.
T07 — Package and gate public exposure
id: HUB-WP-0012-T07
status: todo
priority: high
state_hub_task_id: "0c15cb82-7c59-5a44-8bf0-857ea4438642"
Depends on M1. Owner: rapp-core-hub through existing RAPPCOREHUB-WP-0002-T05, with NetKingdom/platform/reef owners. Pin the verified image, credential references, policy boundary and explicit release exposure setting. Run local, server-dry-run, private root/deny, TLS and consumer gates. Resolve the existing publisher failures in RAPPCOREHUB-WP-0003 separately where required by smoke. Obtain the concrete public-enable approval only after evidence is reviewable. Routine upgrades preserve approved exposure; fresh installs stay private. Rollback retracts public access before any pre-enforcement image is restored.
Done when the approved public surface passes root access, non-root/anonymous denial, no bypass, trusted TLS, revocation and rollback checks. Never enable Ingress just to repair the old public stabilization check ahead of this gate.
T08 — Refine roles, tenant isolation and delegation (Phase 2)
id: HUB-WP-0012-T08
status: todo
priority: medium
state_hub_task_id: "59a0672c-560e-5b43-9d83-9f90d498698f"
Deferred until M1; not an M1 dependency. Hub Core with NetKingdom, User/Tenant Engine, policy and extension owners define tenant admins, ordinary users, recipient rules, delegated agents and per-action/extension permissions. Migrate legacy data with explicit tenant provenance; test query/export/cache/event and MCP isolation before admitting any non-root tenant users. Root's platform grant remains explicit and auditable. Do not create a second workplan merely to defer this task; this plan stays open after M1 until Phase 2 is completed or explicitly re-scoped with a durable owner.
Acceptance checkpoints
- Architecture/source/runtime review captured; new implementation owner is hub-core
- T01 contract review and complete platform surface inventory accepted
- M1: T02–T06 full platform-root access and denial/revocation evidence accepted
- T07: authenticated public exposure separately approved and verified
- Phase 2: T08 delegated and tenant-scoped access accepted
Planning completion is not implementation completion. No authenticated root session or entitlement was tested in the 2026-09-28 review.