Resource-Based Permissions and Delegation

Resource-based permissions and delegation attach access rules to the resource itself rather than defining everything centrally on the subject. This pattern is common in document sharing systems, project ownership, object stores, customer workspaces, repositories, and many SaaS products. Instead of saying “user X has permission Y everywhere,” the system says “this object or collection may be read, edited, shared, or administered by these identities under these constraints.”

This model is powerful because it matches how many products actually behave. A document owner can share one document without becoming a global admin. A project maintainer can invite collaborators to one workspace. A tenant admin can delegate support to a team inside their own tenant. These are natural, useful behaviors. They also create risk when ownership is unclear, shares accumulate, or delegates can expand access farther than intended.

Why It Matters

Resource-based authorization often solves a problem that role-based systems handle awkwardly: object-level or tenant-level ownership. In a document platform, it may be impractical to create a central role for every file or folder relationship. In a customer-facing SaaS product, each tenant may need its own local administrators, contributors, viewers, and delegates. Resource-based permissions make that possible.

The downside is that permission state becomes more distributed. Reviewers can no longer look only at central role assignments. They may also need to inspect object ACLs, share links, workspace membership, owner relationships, and delegation rules. Without strong boundaries, resource-based sharing can grow into invisible privilege creep.

The diagram below shows a typical delegation path.

    flowchart LR
	    A["Resource owner"] --> B["Grant scoped access"]
	    B --> C["Delegate or collaborator"]
	    C --> D["Use allowed actions"]
	    D --> E["Audit and review"]
	    B --> F["Revocation or expiry"]

What to notice:

• the owner is a control point, not just a convenience label
• the share should be scoped and revocable
• audit and review matter because resource-level grants are easy to forget once created

What Resource-Based Authorization Looks Like

Typical examples include:

• document ACLs such as view, comment, edit, or share
• project membership roles such as owner, maintainer, contributor, or viewer
• object-storage policies attached to one bucket or prefix
• customer-tenant administration that is local to one tenant
• delegated case or record access inside a product

This pattern works best when the resource model is clear and ownership is meaningful. If the product cannot reliably determine who owns a resource or what boundary it sits inside, delegation quickly becomes ambiguous.

Delegation Requires Guardrails

Delegation is not the same as unrestricted permission transfer. Strong resource-based models usually constrain delegation by:

• limiting who may delegate
• limiting what can be delegated
• limiting how far delegation can spread
• limiting time or scope
• preserving auditability and revocation

For example, a project owner may grant viewer or editor inside one workspace but may not grant organization-wide billing admin. A tenant admin may delegate user management inside the tenant but not change the platform’s global security policy.

Example: Resource ACL With Delegation Constraints

The following YAML example shows a generic object-level sharing model with bounded delegation.

 1resource:
 2  id: workspace-742
 3  owner: team-alpha
 4  acl:
 5    - subject: user-123
 6      role: maintainer
 7      can_delegate:
 8        - viewer
 9        - contributor
10    - subject: user-456
11      role: viewer
12      can_delegate: []
13  constraints:
14    tenant_id: tenant-acme
15    delegation_may_cross_tenant: false
16    share_expiry_required_for_external: true

Code Walkthrough

This model stays safer than a free-form sharing system because:

• the owner and tenant boundary are explicit
• not every role can delegate
• delegation is limited to certain lower-impact roles
• external sharing is treated more cautiously than internal collaboration

This is the kind of guardrail that keeps product sharing features usable without turning them into uncontrolled privilege spread.

Central Policy Still Matters

Resource-based models do not eliminate the need for central policy. Central rules often still define:

• whether sharing is allowed externally
• which data classes require approval
• which roles may delegate
• which tenant or environment boundaries are absolute

This is why resource-based permissions often complement, rather than replace, RBAC or policy engines. The central model defines guardrails, while the resource model handles local ownership and collaboration.

Common Design Mistakes

• Allowing delegates to re-delegate broadly without clear limits.
• Treating resource ownership as informal rather than explicit and auditable.
• Forgetting to review old object-level shares and access links.
• Allowing cross-tenant or external sharing without strong defaults and visibility.

Design Review Question

A SaaS collaboration product allows any workspace editor to invite anyone else as another editor, with no expiry, no tenant constraint, and no clear owner review. The team argues that this keeps collaboration friction low. Is that a strong delegation design?

No. It prioritizes convenience without preserving ownership boundaries. The stronger design would define who may delegate, to which roles, within which tenant or sharing boundaries, and with what review or expiry rules for broader access. Delegation should be useful, not unbounded.

Appears on These Certification Paths

Application security fundamentals • SaaS authorization design tracks • zero-trust and tenant-isolation learning paths

Continue Learning

This lesson is the bridge from central authorization models into product-level sharing, tenant administration, and delegated control. It becomes especially important again in the later chapter on IAM for applications, APIs, and microservices.

Quiz Time