Authorization: a decision for every object

A support agent may read a customer’s order but cannot refund it. A customer may edit their own address but not a neighbor’s. “Logged in” is too broad to express either rule.

Object authorization: Deciding whether a subject may perform a particular action on a particular resource.

Make the permission sentence explicit

An authorization decision relates a subject to an action on a resource within a context. Role-based access control groups capabilities by job. Attribute-based policies can include ownership, tenant, sensitivity, time, or device state. Relationship-based policies can express membership or delegated access. These are design tools, not automatic security rankings.

Write a sentence such as: a current member of this project may read its non-restricted documents. Each noun becomes a fact the server must establish from trustworthy state.

Identifiers locate; they do not authorize

An unpredictable identifier can reduce accidental discovery, but knowing or not knowing an identifier is not the same as permission. The server must check the requested object, not just the route or menu that linked to it.

Multi-tenant applications need consistent tenant scoping in queries, background jobs, exports, caches, and search results. A correct check on the main page does not protect another path that returns the same data.

Deny clearly and test relationships

Define a default-deny policy, then grant the required capabilities. Evaluate permissions centrally where practical, but still enforce them on every relevant request. Avoid trusting a client-supplied role or tenant without validation.

Use a permission matrix during development: owner, teammate, outsider, suspended user; read, edit, export, delete. Include tests showing both permitted and denied outcomes with synthetic records. Changes to membership should have a defined effect on cached decisions and existing sessions.

Work a small policy before reviewing a large application

Consider a fictional neighborhood archive. Each photo belongs to one album. An active owner may read, edit, or export that album. A currently invited viewer may read, but cannot edit or export. Removal ends future access through the service; it cannot erase copies already saved elsewhere. Albums are private unless a separate publication process explicitly changes that status.

These rows describe this archive’s policy, not universal rules for all products. If the club wants viewers to download individual photos, it must specify that action separately. Calling everything “access” would hide the difference between reading one caption and exporting an entire album.

Identify which component knows each fact

The browser can name the desired album and action. The trusted service establishes the account from its accepted session, looks up the album’s stored ownership, and obtains current membership from the authority that manages invitations. A client-provided label such as “owner” is a request claim, not sufficient evidence of that relationship.

Reviewers should trace the decision to the component that actually releases data or commits a change. A shared policy function helps only when every relevant path supplies the correct subject, action, and resource. An export worker also needs a defined policy when membership changes between scheduling and delivery. The document’s creator and the job’s requester may be different people.

PredictBo starts an export while an owner, then becomes a viewer before the file is delivered. The requirement says delivery requires current owner permission. Is the earlier approval enough?

No. Under this stated requirement, delivery needs current permission and must withhold the file after the role change. A different policy could deliberately preserve an approved job, but that exception would need an explicit requirement and an acceptable disclosure consequence. Faster delivery is not evidence that the requirement was met.

Review the denial as carefully as the success

If the membership service is unavailable, the application cannot treat missing evidence as membership. A protected export can remain pending or be denied with a useful retry message. The choice affects availability, but should not silently broaden access. Record a non-secret operation reference and decision reason so support can explain the outcome without storing the photo contents.

For each row, evidence should show both the decision and its consequence: denied reads return no protected content, and denied edits leave the stored caption unchanged. Include an allowed example to distinguish a working policy from a feature that simply rejects everyone. Check cached results against the same identity and resource assumptions; sharing a cache entry does not create a shared permission.

EXPLORE THE CONCEPT

The same document, different decisions

The document belongs to Project Blue. Explore three callers.

A current Blue member reads it

Permit only if the document classification and membership policy allow reading. Membership is relevant evidence, not a universal grant.

A Blue member deletes it

Reading permission does not imply deletion permission. Evaluate the action separately.

A member of Project Green reads it

A valid account in another project is insufficient. The resource relationship and tenant boundary still apply.

A simplified learning model. It connects to no systems and uses no real data.

Turn the idea into a decision

A permission matrix makes vague requirements testable. Ask what happens for an authenticated outsider, not only for an anonymous visitor.