Δείγμα ελέγχου εξουσιοδότησης μεταξύ tenants

In this example, a tenant represents a separately entitled organisation or legal entity. The protected resource is a particular document version. The subject is the authenticated user or workload, and the action might be read, update, export or share. The central question is whether the current relationship between these objects permits the requested action. A successful login establishes an identity; it does not establish that relationship.

For the narrow fixture, a permit requires an active membership in the document’s tenant and a role allowing the operation. A production model might also consider classification, ownership, delegated access, a transaction workspace and the document’s lifecycle state. Role-based access control is useful for coarse capabilities. Attribute-based or relationship-based policies express restrictions such as an external adviser having access to one engagement, without granting access to every document held by the same office.

A missing attribute, unavailable policy dependency or unrecognised operation needs an explicit outcome. For the protected read in this reference design, an indeterminate decision produces no document data. Public resources, exceptional administrative access and emergency procedures would have separate, documented policies; they should not emerge accidentally from a default branch.

Technical basis: OWASP authorisation design guidance ↗

A tenant identifier in a URL, JSON field or custom header is a requested context, not proof of entitlement. The service first validates the credential for its intended issuer and audience, checks its validity and resolves the actor through trusted identity data. Where an actor belongs to several entities, switching the active entity still requires a server-side membership decision. A syntactically valid UUID and an authenticated request do not make a resource authorised.

The proposed request context contains the subject identifier, selected tenant, allowed action set and the membership or policy revision used for the decision. A document identifier is resolved with this context rather than through a global lookup followed by an optional check. For a shared service account, record both the workload identity and the initiating actor. Treating the service account’s broad database access as the user’s entitlement would lose the boundary the application is meant to enforce.

This separation also improves investigation. An audit record can explain which actor requested which operation, which trusted attributes informed the decision and which policy revision was active. Access tokens and document contents do not need to be copied into routine decision logs to establish that relationship. Diagnostic fields should be chosen deliberately because the log store becomes another location holding sensitive metadata.

The application needs an enforcement point before returning a protected representation or applying an effect. In the proposed design, the repository accepts an authorised tenant context and an object identifier together; updates constrain both the target and the permitted fields. Parameterised queries prevent data being interpreted as query syntax. They do not decide whether an otherwise valid query is entitled to return a particular row.

Database row-level security can add another boundary. PostgreSQL, for example, allows policies to govern which existing rows can be selected and which new or changed rows are acceptable. Its documentation also identifies bypass behaviour: superusers and roles with BYPASSRLS bypass row security, and table owners normally bypass it unless configured otherwise. A real review therefore tests through the actual application role, including its ownership, privileges and security-definer functions, rather than assuming a policy’s presence proves enforcement.

Technical basis: PostgreSQL row security policies and bypass conditions ↗

Connection reuse is a separate test condition. If the application supplies tenant context through connection state, it must establish that context for the operation and prevent it surviving into another tenant’s use of the connection. The precise mechanism depends on the driver, pooling mode and transaction model. We would exercise alternating-tenant requests and failure paths under the deployed configuration, including a rolled-back transaction and an interrupted request.

A correct database query can be undermined by a shared cache entry. If a representation varies by tenant, user entitlement or policy revision, the cache design must preserve those distinctions. Authorise before serving protected cached data; a namespaced key does not replace an access decision. Permission changes also need a defined invalidation or freshness contract. Otherwise, a user removed from an engagement may continue to receive a previously authorised representation.

Technical basis: OWASP multi-tenant cache and asynchronous-work isolation ↗

These are separate trust transitions. The corrective design should state where authority is checked again and where a time-limited capability is intentionally relied upon. The customer can then judge the remaining exposure window instead of receiving a vague assertion that all links are secure.

Consider an editor who starts a document update just before membership is revoked. A permission check and a later database write are two observations of state unless the implementation connects them. This is the time-of-check/time-of-use problem. For this reference design, the owner must specify the operation’s decision point: the state against which permission and resource version must both be valid.

Within one database, an appropriate transaction, conditional update or locking strategy can connect those checks. Across a separate identity service and business database, a local transaction cannot make both systems change atomically. Options include a versioned authorisation contract, a final permission check at the executor and a documented revocation window. The required consistency and availability trade-off depends on the operation’s consequence; a confidential export deserves different scrutiny from a harmless display preference.

The retest should schedule permission and resource changes at controlled points in the workflow, then inspect the effect, not just the HTTP response. A denied update must leave the business record unchanged. An accepted operation must be attributable to a specific permitted state. Where immediate revocation cannot be guaranteed, that limitation belongs in the closure record with an owner and an agreed compensating measure.

The 16-case matrix above is the smallest explanatory model, not a target coverage percentage. A real test set follows the agreed policy: direct and inherited membership, removed and suspended users, delegated advisers, service identities, resource lifecycle changes and alternate delivery paths. Positive cases matter because a fix that denies every request would preserve confidentiality while breaking the service.

For each case, retain fixture identities, prerequisites, expected policy outcome, observed content or effect, request correlation identifier, deployed build and policy revision. Compare what the receiving client obtains and what the data store changes. A 403 response after a partial write is still a failure; a 200 response containing a generic denial is not proof that another tenant’s record was disclosed.

The commissioning team receives a trace from business rule to test to observed result, with exceptions listed explicitly. That makes the work useful to engineering, risk and procurement: it identifies which boundary was demonstrated, which implementation paths were covered and which assumptions would require a new review after the next product change.