Ir al contenido principal
Petanque Life

Capability-baserad åtkomstkontroll

F16.12 6 funcionalidades Planificado

En resumen

Capability-based access control on every endpoint with OrgNode-scoped role assignment, per-tenant capability configuration that lets federations disable whole domains, full audit logging of grants, revocations and denials, time-limited capability grants for vacation cover and short-term project work, and reusable capability templates so a federation can spin up new role archetypes without hand-wiring every individual permission.

Cómo funciona

Every endpoint declares the capability it requires and goes through a centralised check before any business logic runs. POST /capability-check verifies a single capability for the calling principal; POST /capability-check-batch fans out across many for UI scenarios where a screen wants to know which actions to render. A denied check is not silent — it lands in the audit log under AuditLogDomain.CAPABILITY with actor, IP and the capability that failed, so an investigator can see who probed for what.

Capabilities aggregate over OrgNodes. GET /users/{user_id}/orgnode-capabilities/{org_node_id} computes the effective capability set for a user at a given OrgNode by walking their role assignments and filtering by scope (system, tenant, org_node). A user might be a club secretary at one club and a referee at the regional level; the resolver returns the right set for the context the request is made in, so a federation admin's cross-OrgNode view does not leak read-down by accident.

Federations get configurability through TenantCapabilityConfig: GET/PUT /tenant-capability-config/{tenant_id} lets a tenant admin disable specific capabilities or restrict the active set to particular domains. A national federation that does not run anti-doping in-house can disable the ANTI_DOPING domain; a flat-hierarchy nation can disable OrgNode capabilities it does not need. Every config change is audited.

Time-limited grants cover the operational reality of summer cover and short-term project work. Role assignments carry valid_from / valid_until; GET /capability-grants/expiring lists grants approaching expiry so a manager can extend or close them before they lapse, and GET /capability-grants/summary gives a dashboard-level view of who has what right now. Capability templates encode common role archetypes — club_secretary, regional_umpire_coordinator, treasurer — as named bundles with wildcard expansion at apply time. POST/GET/PUT/DELETE /capability-templates manages the catalogue and POST /capability-templates/{id}/apply assigns the bundle to a user-and-OrgNode pair, so onboarding a new club secretary takes one call instead of forty.

Capacidades clave

  • Capability-check on every endpoint with batch-check for UI rendering and audit on denial
  • OrgNode-scoped capability resolution filtering by system / tenant / org_node scope
  • Per-tenant capability configuration (disable capabilities, restrict to enabled domains)
  • Capability audit log under dedicated AuditLogDomain.CAPABILITY for all grant/revoke/deny/config events
  • Time-limited capability grants with valid_from / valid_until and expiring-grants visibility
  • Capability-grants summary endpoint for dashboard-level access oversight
  • Reusable capability templates with wildcard expansion and one-call apply

En la práctica

A regional federation hires a summer intern to help with license processing. The federation admin opens capability templates, picks license_processor (a bundle: license:read, license:write, payment:read, audit:read on the regional OrgNode), and applies it to the intern's user with valid_from today and valid_until 31 August. Two months later the expiring-grants dashboard surfaces the grant a week before lapse; the admin chooses not to extend, the role auto-revokes on the cutoff date and every action the intern took is preserved in the audit log under their actor_id.

A capability:revoke event lands on the audit trail; nobody had to remember to clean up.

Funcionalidades de este subsistema

6
ID Status Funcionalidades
F16.12.01 Entregado Capability-check på varje endpoint — POST /capability-check och POST /capability-check-batch verifierar att anroparen har erforderlig capability. Nekad åtkomst loggas i audit log. Implemented (PL-F1612). ✅ PL-F1612
F16.12.02 Entregado Capability-tilldelning per OrgNode-roll — GET /users/{user_id}/orgnode-capabilities/{org_node_id} beräknar effektiva capabilities för en användare vid en specifik OrgNode, filtrerar på scope (system/tenant/org_node). Implemented (PL-F1612). ✅ PL-F1612
F16.12.03 Entregado Konfigurerbara capabilities per tenant — GET/PUT /tenant-capability-config/{tenant_id} låter varje federation inaktivera capabilities och begränsa till specifika domäner. TenantCapabilityConfig-modell med disabled_capabilities och enabled_domains. Implemented (PL-F1612). ✅ PL-F1612
F16.12.04 Entregado Capability audit log — GET /capability-audit querying av capability-domänens audit-logg. Alla grant/revoke/deny/config-ändringar loggas under AuditLogDomain.CAPABILITY. Implemented (PL-F1612). ✅ PL-F1612
F16.12.05 Entregado Tidsbegränsade capabilities (sommarvikariat) — GET /capability-grants/expiring listar utgående grants, GET /capability-grants/summary ger dashboard-översikt. Stöd för valid_from/valid_until på rolltilldelningar. Implemented (PL-F1612). ✅ PL-F1612
F16.12.06 Entregado Capability-templates per roll-arketyp — POST/GET/PUT/DELETE /capability-templates, POST /capability-templates/{id}/apply. CapabilityTemplate-modell för användardefinierade capability-buntar med wildcard-expansion vid applicering. Implemented (PL-F1612). ✅ PL-F1612