Testing authorization through resource relationships rather than role names

Goal

Check whether a caller can act on a particular object through the relationship the product actually promises. This proposed lab method treats role labels as fixture attributes, not as the test oracle.

Prerequisites

Use an isolated project tracker with synthetic accounts: a project owner, a project member, and an unrelated account. Create an issue owned by the project and write the intended read, edit, and transfer rules before issuing requests.

Steps

1. Build a table whose rows identify caller, project, issue, operation, and expected decision. Include a member of another project with the same role name; matching labels must not silently stand in for membership.

2. Run an allowed operation first and verify its actual state change. A rejected request has little diagnostic value if the endpoint, authentication setup, or fixture itself is broken.

3. Change only the caller relationship, keeping the target and operation fixed. Capture the decision and inspect the synthetic issue after the request, rather than accepting an error message as proof of no change.

4. Change membership while keeping the account and issue identifiers stable. Repeat the matrix so that expectations follow current relationships rather than the identities used when the fixture was created.

5. When a mismatch appears, trace which relationship reached the authorization decision. Add that exact relationship combination as a regression case, and rerun the originally allowed operation after the repair.

Expected result

The resulting table should distinguish policy failures from broken fixtures and document a concrete object-level invariant for each operation.

Limits and test basis

This matrix covers the modeled relationships only. Separate tenant, lifecycle, and delegated-access policies need their own rows; a passing role matrix cannot establish complete authorization coverage. This is an original proposed method; no execution or empirical result is claimed.