Commit graph

54 commits

Author SHA1 Message Date
139b6ff351 Harden the authorization-code grant and UserInfo verification
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 37s
Closes the local protocol surface of gap G01 from the scope assessment
(KEY-WP-0016). The browser grant validated PKCE, client id and scopes but left
four bindings unenforced, and UserInfo verified less than the caller CLI does.

Authorization-code path: bind the exchange to the redirect URI the code was
issued for, refuse clients whose registration does not permit the grant, and
authenticate confidential clients with a digest-based constant-time comparison
over the same credential sources as the service grant. An empty grantTypes stays
an implicit authorization-code client, matching config validation.

Code consumption: SessionStore.Consume reads and deletes under one lock. The
previous Get/Delete pair spanned JWT signing, and the added test reproduces the
race against that version -- 9 of 16 concurrent exchanges succeeded, and a
failed exchange left the code replayable.

UserInfo: check the JOSE header algorithm before trusting the signature, require
the configured issuer, and require an access token rather than accepting an ID
token of the right shape. Purpose is decided on the scope claim so the issued
token contract, which consumers pin exactly, does not change.

SCOPE.md and the assessment record which bindings are now enforced and that the
Authelia upstream-trust assumption remains open, so G01 is not fully closed and
no profile-conformance claim is made.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
2026-09-06 22:43:47 +02:00
7a6666d1f9 Align approval registrations to the tenant:platform decision
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 33s
Operator decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6 accepts tenant:platform
as the platform management tenant for the Glas approval chain, requiring exact
spelling across the approval store, the service-client JWT claim and the
lifecycle CheckRequest.

Changes the tenant field on secrets-engine-approval and approval-engine-operator
only, in the registration fixture and the provisioning packet. Unrelated clients
and the human directory default keep tenant:coulomb, and no audience, scope,
subject, role, lifetime or MFA grant changes.

Adds issuance evidence that the approval shape emits tenant:platform exactly and
never an alias the caller requests, that the OpenBao client gains no
cross-tenant reach, and a fixture guard pinning every reviewed client's tenant.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
2026-09-06 22:30:32 +02:00
da7bc31d45 Document tenant claim ownership and prove registration binding
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 32s
Answers the GLAS-WP-0015 tenant-alignment request. The JWT tenant is
tenant:coulomb for all four reviewed service registrations; the approval store
tenant and the policy tenant belong to other owners and KeyCape does no
normalization between them. No mapping is invented and no live registration
changes.

Adds regression tests proving the tenant claim is bound at registration and is
not influenced by request parameters, that distinct registrations never carry
each other's tenant, and that human tokens fall back to the platform tenant
rather than an empty claim.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
2026-09-06 20:33:06 +02:00
30fa8570aa Document actual capabilities and assess scope against intent
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06e87-e039-7ed2-b85c-20ad37f8a21b
2026-09-05 01:27:16 +02:00
b989de4e90 Add native verified login and service-token commands
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 41s
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06e87-e039-7ed2-b85c-20ad37f8a21b
2026-09-05 01:08:58 +02:00
403904b901 Add bounded resource audiences and enforce browser scope grants
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 36s
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06e87-e039-7ed2-b85c-20ad37f8a21b
2026-09-05 00:41:17 +02:00
repo-manager
b8dda4115a repo.work.assign_missing_identifiers
source: repo-manager
reason: deterministic projection registration

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a058f3-8ba0-7692-a042-9a870fc3d663
2026-09-01 01:36:20 +02:00
3ed3a391d6 docs: close canonical UserInfo repair
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a058f3-8ba0-7692-a042-9a870fc3d663
2026-09-01 01:36:12 +02:00
153258b9d3 Fix UserInfo canonical subject resolution
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 23s
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a058f3-8ba0-7692-a042-9a870fc3d663
2026-08-31 23:41:29 +02:00
270a065383 fix(workplans): adopt ADR-007 derived identifiers for unregistered records
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.

Records central already holds were deliberately left untouched.

Refs CUST-WP-0068-T06

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
2026-08-25 20:13:23 +02:00
6a996bd71e security: rotate exposed KeyCape credentials
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02e3f-7301-7622-9be1-12e5f352881c
2026-08-23 14:26:36 +02:00
repo-manager
bb6dc8d7fc chore(registrar): assign State Hub identifiers
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02e3f-7301-7622-9be1-12e5f352881c
2026-08-23 13:57:59 +02:00
b7b4985baa Track KeyCape live secret exposure recovery
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02e3f-7301-7622-9be1-12e5f352881c
2026-08-23 13:56:09 +02:00
repo-manager
d150be1097 chore(registrar): assign State Hub identifiers
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02e3f-7301-7622-9be1-12e5f352881c
2026-08-23 13:19:35 +02:00
48fb556ce8 Use canonical workplan ID for callback admission
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02e3f-7301-7622-9be1-12e5f352881c
2026-08-23 13:16:46 +02:00
f5cf77fa0c Admit operator-tunneled OpenBao callback
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 23s
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02e3f-7301-7622-9be1-12e5f352881c
2026-08-23 13:16:21 +02:00
repo-manager
34fadae1c1 chore(registrar): assign State Hub identifiers
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02e3f-7301-7622-9be1-12e5f352881c
2026-08-23 13:13:38 +02:00
efce3e9331 Implement KeyCape provider and service identity contracts
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 25s
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02e3f-7301-7622-9be1-12e5f352881c
2026-08-23 13:10:13 +02:00
b6af6c5268 Finish KEY-WP-0008: registration handoff and client MFA isolation
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 34s
Add signed registration/enrollment handoffs, per-request assurance
policy with login-session isolation, and /logout. coulomb-social
stays AAL1 unless acr_values or another client raises the bar.
2026-08-16 01:05:27 +02:00
fff9e39478 docs: point at RMASTER-WP-0019 after master prefix rename 2026-08-14 14:29:19 +02:00
3bef507cb8 KEY-WP-0008: honor per-client mfaRequired and acr_values step-up
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 30s
Allow coulomb-social ordinary login at AAL1 via mfaRequired: false while
keeping provider requireForAll for clients without an override. Preserve
explicit acr_values=aal2 for step-up.
2026-08-09 22:42:51 +02:00
a6ff5384b1 Finish portal OIDC integration 2026-07-29 22:59:38 +02:00
2465481e3c Complete Binky tenant onboarding 2026-07-29 22:13:53 +02:00
abd9e6fa2b Record Binky MFA login acceptance 2026-07-29 22:05:18 +02:00
72b0eb404c Record platform-root authorization fix 2026-07-29 21:33:37 +02:00
41d2e1d1f6 Record Binky password handoff readiness 2026-07-28 17:56:14 +02:00
49a8992d6e Advance Binky human onboarding 2026-07-28 16:49:27 +02:00
070c38f447 Record suspended identity enforcement 2026-07-28 01:33:24 +02:00
76da0237ff Bind portal OIDC workplan to State Hub 2026-07-28 00:43:56 +02:00
e8b4eded88 Map explicit tenant groups into OIDC claims
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 26s
2026-07-28 00:34:19 +02:00
993a4dd589 Register user-engine portal OIDC client 2026-07-28 00:06:38 +02:00
1cd137cd9d Route Binky onboarding through user portal 2026-07-27 22:31:43 +02:00
e54bcd9a40 Advance Binky identity onboarding 2026-07-27 20:39:13 +02:00
881fffc079 Complete KeyCape service-token rollout
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 25s
2026-07-27 20:17:55 +02:00
custodian-sync
e4464278e7 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-07-27:
  - KEY-WP-0006-T04: progress → wait
2026-07-27 20:03:31 +02:00
e877d2752d Implement KeyCape service-token issuance
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 47s
2026-07-27 20:03:07 +02:00
86e6c083f7 Define Qonto runtime identity contract 2026-07-26 13:34:56 +02:00
44da5f5f99 KEY-WP-0005-T02-T03: cached tenant_roles claim, close workplan
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 1m21s
New internal/adapters/tenantengine package, mirroring
internal/adapters/{lldap,privacyidea,authelia}'s shape: Client.Roles()
calls tenant-engine's cache-read endpoint. Fails open by construction --
unreachable, non-200, malformed body, or a nil *Client all return
(nil, false), never an error to specially handle. Wired into
TokenHandler.TenantEngine (nil by default, existing tests unaffected);
token.go stamps tenant_roles only when ok.

7 adapter tests plus 3 TokenHandler-level tests proving the actual
required behavior end-to-end: present when reachable, token issuance still
200 with every other core claim intact when unreachable (tenant_roles
simply absent -- the literal done-criteria), absent when not configured.

Real bug found and fixed at the source, not worked around: the first live
cross-process check (real flex-auth, real tenant-engine, this adapter)
returned tenant_not_found for a tenant that existed -- tenant-engine's read
endpoint was keyed by its internal tenant_id, but key-cape only ever has
the tenant's profile identifier. Fixed in tenant-engine
(ADHOC-2026-07-24), re-verified with the same live three-process chain --
roles=[IAM] ok=true.

Workplan closed: T01-T03 done. Explicitly still open: client_credentials /
service-token issuance -- no such flow exists in token.go at all, a
materially larger separate piece of work than either task here.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-24 00:18:17 +02:00
f1f7fa9dd7 KEY-WP-0005-T01: IAM Profile core claims for the human PKCE flow
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 1m50s
Verified first: grant_types_supported advertises client_credentials in
discovery.go, but token.go only ever accepted authorization_code -- no
service-token issuance path exists at all. Building one from scratch is
materially bigger than extending the existing flow; explicitly not
attempted here, left open in the workplan rather than declared done.

What shipped for the human Authorization Code + PKCE flow:

- domain.User.Tenant (new, omitempty) + token.go's effectiveTenant():
  falls back to tenant:coulomb (this workstation's actual tenant, ADR-0006)
  when unset -- never an empty tenant claim, never a silent reassignment.
- principal_type: "human", unconditional.
- groups/roles promoted from scope-gated to unconditional core claims,
  always [] not null when empty. One pre-existing test asserted the old
  scope-gated groups behavior -- updated to match the new intentional
  behavior, not left failing or reverted.
- assurance built from PKCESession.MFAVerified (new field, threaded
  through completeAuthorization's two call sites in authorize.go) --
  whether MFA was actually verified in this session, not static enrollment
  state. aal2 only when required-and-passed this time, aal1 otherwise.

go build/vet clean, go test ./... green repo-wide. Two new authorize_test.go
cases assert MFAVerified on both paths. tests/profile/profile_test.go's
TestCompleteTokenFlow (the repo's own full HTTP integration test) extended
with real value assertions for all five claims, not just presence checks.

Python conformance tool not run against a live instance (needs the full
Authelia+LLDAP+privacyIDEA stack); TestCompleteTokenFlow's real HTTP round
trip covers the equivalent claim checks instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-24 00:03:31 +02:00
8059f65a1b chore(consistency): write back state_hub ids for KEY-WP-0005 [auto]
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 23:52:13 +02:00
260ff9cc99 Draft KEY-WP-0005: IAM Profile core claims (tenant, principal_type, roles, assurance, tenant_roles)
Discovered while planning tenant-engine's flex-auth WriteAuthorizer
(TEN-WP-0003): src/internal/server/oidc/token.go emits none of
iam-profile_v0.3.md's Core Claims yet -- not tenant, principal_type,
groups, roles, or assurance. tenant_roles isn't a small addition on top of
existing tenant support; it's the last, optional claim on top of a
baseline that doesn't exist yet.

Registered, not implemented -- security-sensitive Go token-issuance code
deserves dedicated context before changing, not a rushed edit from a first
read of the file.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 22:47:00 +02:00
df26aee844 KEY-WP-0004-T01: adopt tenant:<grouping>:<name> identifier, binky -> friendly
Bernd's decision: role words (customer/vendor) collide with the separate
capability-role dimension a tenant can hold (PLTF/IAM/VEN/CUS, per
net-kingdom/docs/princedom-isolation-exploration.md's unratified model --
Binky itself is both CUS and, later, VEN). Tenants are grouped instead by
onboarding-risk/entity-shape, orthogonal to role: trial, friendly, single,
small, medium, large, enterprise, consumer, family, community, association,
agentic.

Binky maps to friendly -> tenant:friendly:binky, replacing the earlier
tenant:customer:binky throughout this workplan.

Two open questions flagged, not resolved here: where tenant:coulomb (the
platform's own internal/reference tenant) fits this external-shaped grouping
list, and whether net-kingdom should ratify this list into
iam-profile_v0.2.md's Tenant Claim section, since it currently still
documents the old customer/sandbox suggested identifiers and NetKingdom
owns that canon per ADR-0011.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 15:45:43 +02:00
7ddc48d3cd chore(consistency): register KEY-WP-0004 in State Hub [auto]
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 14:35:36 +02:00
b9a7d1b008 Draft KEY-WP-0004: Binky Hedgehog GmbH as first tenant + qonto-assistant workload identity
Provisions the first real NetKingdom tenant (tenant:customer:binky, matching
the slug already live in production OpenBao paths) with a human tenant-admin
user and a workload-identity OIDC client for qonto-assistant's MCP callers,
routed through secrets-engine for secret custody and ops-warden for
discoverable, minimal-touch credential access. Closes Gap #1 flagged in
qonto-assistant's QONTO-WP-0003 closure (no OIDC issuer existed in the fleet).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 14:34:40 +02:00
2fd69f0374 Normalize agent instructions and workplan frontmatter (STATE-WP-0067)
Some checks are pending
Build and Publish Container Image / build-and-push (push) Waiting to run
- Align agent files with on-disk workplan prefixes (infer from workplan ids)
- Set workplan domain to registered domain_slug; add topic_slug where applicable
- Repair frontmatter delimiter formatting; migrate legacy task status literals
- Regenerate AGENTS.md, CLAUDE.md, and .claude/rules from State Hub templates
2026-06-22 23:16:27 +02:00
afc01456a5 Fixed workplan frontmatter 2026-06-22 18:40:55 +02:00
1d68639225 Align KeyCape image namespace with deployment 2026-05-24 17:17:37 +02:00
7e22fcf3c7 bootrapping support 2026-05-24 17:03:01 +02:00
18dbad68ed feat(close): mark KEY-WP-0002 done — all 6 tasks complete
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-21 23:33:28 +00:00
7822ba0703 feat(image): KEY-WP-0002 T01/T02/T06 — Makefile image targets, Gitea Actions workflow, README CI docs
- Makefile: add IMAGE_REGISTRY/IMAGE_REPO/IMAGE_TAG vars + image, push, image-tag targets
- .gitea/workflows/image.yaml: build+push on main push and v* tags via metadata-action
- README: Container Image section with pull/build/push/CI secret docs

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-21 23:27:39 +00:00