QONTO-WP-0004-T04. Modeled directly on examples/tenant-engine/: one resource type (finance-snapshot), one action (finance.qonto.read), two registered subjects (an agent-harness session identity and the founder's human identity), and a Rego policy gating on resource.system + action + subject.type + tenant match. Tenant capability-role/plan liveness (VEN/CUS) is deliberately NOT encoded here -- that's qonto-assistant's separate tenant-engine live-lookup check, per this package's own scope note. Verified: flex-auth test-policy (6 rego tests + 6 fixtures, all pass), load-registry, and CLI check for both an allow and a deny case. Also verified end-to-end over real HTTP: a live flex-auth serve loaded with this exact registry+policy, hit by qonto-assistant's actual FlexAuthCheckClient (not a mock) -- allow for tenant:friendly:binky, deny (wrong_tenant) for a mismatched tenant. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| check_request_allow_read.json | ||
| check_request_deny_wrong_tenant.json | ||
| policy_fixtures.yaml | ||
| policy_package.md | ||
| protected_system_manifest.yaml | ||
| README.md | ||
| registry_snapshot.json | ||
| subject_manifest.yaml | ||
qonto-assistant Consumer Integration Fixtures
QONTO-WP-0004-T04. Registers qonto-assistant as a flex-auth
protected-system consumer, gating its finance.qonto.read capability
(the live-authorization half of docs/SecurityPractice.md — the other half
is a tenant-engine capability-role/plan liveness check, deliberately kept
separate; see policy_package.md's scope note).
Files
| File | Purpose |
|---|---|
protected_system_manifest.yaml |
Resource type (finance-snapshot) and action (finance.qonto.read) |
subject_manifest.yaml |
Registered callers: an agent-harness session identity and the founder's human identity, both in group:qonto-assistant-readers |
policy_package.md |
Rego rules + embedded tests gating the read action |
policy_fixtures.yaml |
Allow/deny request/decision pairs, referenced by policy_package.md's frontmatter |
registry_snapshot.json |
Merged systems/subjects/groups snapshot assembled from the two manifests above, loadable by flex-auth serve/check/load-registry |
check_request_allow_read.json, check_request_deny_wrong_tenant.json |
Standalone example requests for flex-auth check |
No resource_manifest.yaml — like tenant-engine's tenants, qonto-assistant
doesn't have a fixed enumerable resource inventory to register; the single
finance-snapshot resource type is declared on the protected-system
manifest and that is sufficient for this policy's coarse per-actor/per-tenant
gate.
Verified
go build -o bin/flex-auth ./cmd/flex-auth
# Rego rules + embedded tests + fixtures, all pass:
bin/flex-auth test-policy -file examples/qonto-assistant/policy_package.md
# Registry loads cleanly:
bin/flex-auth load-registry -file examples/qonto-assistant/registry_snapshot.json
# Individual requests via the CLI:
bin/flex-auth check \
-registry examples/qonto-assistant/registry_snapshot.json \
-policy examples/qonto-assistant/policy_package.md \
-request examples/qonto-assistant/check_request_allow_read.json
# End-to-end over real HTTP: a live `flex-auth serve` loaded with this exact
# registry+policy, hit by qonto-assistant's actual FlexAuthCheckClient (not
# a mock) -- see qonto-assistant/tests/test_flex_auth_client.py and
# tests/test_live_authorization_gate.py, and the manual curl walkthrough
# below:
bin/flex-auth serve -addr 127.0.0.1:9099 \
-registry examples/qonto-assistant/registry_snapshot.json \
-policy examples/qonto-assistant/policy_package.md
# from another shell:
curl -s -X POST http://127.0.0.1:9099/v1/check -H "Content-Type: application/json" \
-d @examples/qonto-assistant/check_request_allow_read.json
# -> effect: allow, reason: finance_read_policy_matched
curl -s -X POST http://127.0.0.1:9099/v1/check -H "Content-Type: application/json" \
-d @examples/qonto-assistant/check_request_deny_wrong_tenant.json
# -> effect: deny, reason: wrong_tenant
Related
qonto-assistant/docs/SecurityPractice.mdqonto-assistant/workplans/QONTO-WP-0004-security-hardening-and-scale-to-zero.mdexamples/tenant-engine/— the pattern this was modeled onnet-kingdom/docs/adr/ADR-0014-tenant-capability-roles-and-tenant-engine-ownership.md