Files
infospace-bench/infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-delegated-authorization.md

2.6 KiB

Pattern: Delegated Authorization

Status: reviewed Readiness target: RL3 production Primary owners: flex-auth, NetKingdom

Problem

Identity providers and application code should not become the scattered home for every tenant, resource, and object-level authorization rule.

Context

Use this pattern for protected systems that need consistent decisions for tenant-scoped resources, privileged operations, object storage, agent access, and application APIs.

Forces

  • Applications need local enforcement, but policy needs central shape.
  • Tenant, resource, action, assurance, and context must travel together.
  • Some decisions can be delegated to PDP runtimes such as Topaz.
  • Deny reasons and obligations need to be auditable.

Solution

Use flex-auth as the canonical authorization boundary. Callers submit a standard decision request; flex-auth evaluates directly or delegates to Topaz; applications enforce the returned allow/deny, obligations, and audit metadata at the boundary.

Implementation Sketch

  1. Register protected systems and resource/action vocabulary.
  2. Define the decision envelope and CARING descriptors.
  3. Add policy packages with tenant/platform separation.
  4. Delegate to Topaz where ReBAC or policy runtime support is useful.
  5. Return stable allow/deny, reason, obligation, and audit fields.
  6. Require applications to enforce decisions before resource access.

Failure Modes

Failure Mitigation
App ignores deny obligations add conformance tests at enforcement points
Policies mix platform and tenant authority separate policy packages and review paths
Decision context omits tenant fail closed
PDP outage becomes implicit allow fail closed except documented emergency flows
  • Authorization and access control.
  • Tenant isolation.
  • Application and API security.
  • Observability, detection, and audit.

Maturity

Reviewed. This is a core NetKingdom boundary and should become canonical once flex-auth conformance fixtures are stable.

Verification

  • Decision envelopes include actor, tenant, resource, action, context, obligations, reason, and audit id.
  • Enforcement points deny when flex-auth denies or is unavailable.
  • Topaz delegation is visible in decision records.
  • Tenant and platform policy packages are separated.

Research Basis

Seeded by the policy decision point/enforcement point pattern, tenant scoped authorization, API authorization, and CARING modeling notes.

References

  • NetKingdom platform identity/security architecture.
  • Initial exploration: Authorization and access control.