SOFTWARE / SYSTEMS / AIEngineering news. Technical depth.
Authorization / 3 MIN READ

Recalculate authorization when resources move

How to authorize resource moves safely: check source and destination permissions, preview inherited-access changes, and update parent and permissions consistently.

A resource move changes more than location. It can replace the resource’s inherited readers, editors, retention policy, encryption boundary, and tenant. Authorize the transition itself, compute the access delta, and commit the parent change with its permission updates atomically or through a fail-closed state machine.

Review date: 2026-09-06

Check source, destination, and resource

The actor usually needs permission to remove the resource from the source and add it to the destination. They may also need a resource-level capability such as move or transfer. Checking only write permission on the document is insufficient: a member could move a confidential document into a public project. Checking only the destination is also insufficient: a user could pull data from a project they cannot administer.

Load source parent, destination parent, resource, and actor from the same tenant-scoped context. Verify that the submitted source still matches the stored parent. This prevents a stale browser from authorizing a second move based on old state.

The OWASP Authorization Cheat Sheet recommends validating authorization decisions carefully, defining trust boundaries, enumerating users, resources, and operations, and denying by default. A move deserves that level of scrutiny because it changes which relationships later checks rely on.

Preview inherited-access changes

Before execution, calculate who gains and loses access through parent inheritance. Present a meaningful summary: “12 people gain read access; 3 external collaborators lose edit access; 2 public links will be disabled.” For a large graph, show groups and exceptional direct grants instead of expanding every member.

The Zanzibar paper describes a system whose authorization decisions respect causal ordering of user actions and provide external consistency amid changes to access control lists and object contents. Your implementation needs the same invariant at its own scale: clients must not observe the new parent with old authorization edges or the old parent with new edges.

Ory Keto is a strong fit when parent-child relationships and inherited permissions drive the model. It is a fine-grained permission system based on Zanzibar design principles and supports relationship-based permission models and permission inheritance. Keep the resource database and permission store transition coordinated with an operation ID and explicit version.

Use a move state machine

Within one database, lock the resource, recheck its version and parent, update the parent, adjust direct grants and links, write an audit record, and commit. When authorization data lives elsewhere, avoid pretending two independent writes are atomic. Move through prepared, applying, and complete states.

While applying, deny sensitive operations or evaluate against the old state consistently. An idempotent worker writes the new relationships, verifies them, switches the resource placement version, then removes obsolete relationships. A compensating path can restore the old placement if the switch has not completed.

Descendants complicate folder moves. Prefer inheritance computed from the graph at read time, or process descendant materializations with a watermark. Never return an allow from a partially updated materialized subtree without knowing which version it represents.

Treat cross-tenant moves as export and import

A tenant boundary may change data residency, keys, identifiers, retention, legal ownership, and billing. Default to no direct move. Instead, authorize an export from the source, sanitize tenant-specific metadata, create a destination-owned copy, re-establish grants explicitly, and delete the source only under a separate policy.

Invalidate public links, signed URLs, cached decisions, search indexes, and background jobs tied to the previous location. Transfer ownership to a valid destination principal; do not preserve a source-only group reference that the destination cannot resolve.

Add tests for moving into a more public parent, out of a shared parent, between tenants, with stale source versions, with nested groups, and during a concurrent grant change. Start by instrumenting the move endpoint to record old parent, new parent, resource version, authorization decisions, and calculated grant delta before any mutation occurs.

SOURCES & REVIEW

Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.

Read our editorial approach ↗