Permission inheritance: Enforcement architecture

Effective permissions are computed deterministically from role, group, and resource inheritance with deny-wins rules, materialized views for audit, and explicit handling of grant overlays.

Package status: AI-assisted reference package. Static package validation has passed; implementation scenarios remain not run and human domain review is required before stable adoption.

Decision

Compute effective access by walking the resource hierarchy up to a bounded depth, unioning role and group allows, overlaying active temporary grants, then applying explicit deny on nearer resources so explicit deny wins over an active grant unless a separate auditable break-glass override is recorded.

Scope

• Inheritance along tenant, folder, project, or object trees.
• Direct assignments, group-derived roles, and temporary grant overlays.
• Explain/debug API behavior and cross-tenant isolation during inspection.
• Materialized effective-access snapshots for audit diffing after changes.

Outside this block

• Temporary grant issuance workflow and expiry sweeps (see temporary access block).
• Authentication and credential validation.
• UI for permission management.

Contract

• Allow permissions propagate from ancestor to descendant until depth limit unless blocked by explicit deny on an intermediate or leaf resource.
• Evaluation order is fixed: union role and group allows, apply active temporary grants, then apply explicit denies. Explicit deny on a resource overrides inherited allow and active grant allows for the same action on that resource and descendants (default: no grant-wins exception).
• Break-glass elevation, when enabled at all, is a separate auditable override path with its own ticket and expiry; it is not implied by ordinary temporary grants.
• Temporary grants add allows only while status is active and within the time window; expired or revoked grants are ignored before deny evaluation.
• Effective access computation is deterministic: identical inputs produce identical decision hashes logged to audit snapshots.
• Enforcement middleware and explain API use the same engine version and rule ordering; divergent results are treated as defects.
• Cross-tenant explain requests never reveal resource paths or roles from other tenants.
• Depth beyond the profile maximum yields deny with reason code depth-exceeded, not partial silent allow.
• When inheritance inputs change, recompute completes within the profile stale-read bound or enforcement fails closed for affected resources.

Implementation guidance

• Represent resources as stable path IDs; store bindings as (subject, role, scope_path) tuples.
• Materialize group memberships asynchronously but block admin UI claims of propagation until materialization completes.
• Use effective-access-cases.yaml as fixture data for table-driven tests in the adopting repository.
• Version the engine and include version in audit snapshots to support future rule changes.

Failure handling and safeguards

• On partial materialization failure, deny elevated actions only for affected subjects and affected resources within the affected tenant until recompute succeeds. If the exact resource scope cannot be established safely, fail closed for those subjects across that tenant, never across unrelated tenants.
• Circular group membership detection aborts expansion and alerts rather than looping infinitely.
• If explain API is disabled in production, provide break-glass read-only tooling with stronger auditing.
• Do not cache effective access across tenant boundaries.

Verification and operations

• Compare enforcement decisions to explain output samples on every deploy via smoke tests.
• Track recompute latency, stale read incidents, and depth-exceeded denials.
• Alert with tenant, subject set, and resource-scope evidence so the fail-closed boundary can be reviewed without broadening it accidentally.
• Review deny-wins conflicts when admins complain about unexpected denies; export snapshot diff.

Adoption assumptions

• Names and structures in example.yaml and effective-access-cases.yaml are an adoption profile, not universal defaults.
• Teams map their resource tree and role catalog to the inheritance model explicitly.

References

• owasp-authorization