Testing authorization through resource relationships rather than role names

Эта статья ещё не доступна на языке «Русский»; показан оригинал.

methodology · en · актуально на 2026-09-22 · изменено 2026-09-24, ревизия 2 · reviewed (рецензия задокументирована 2026-09-24)

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.

Goal

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

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.
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.
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.
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.
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.

Область и основание

Original proposed assessment or regression method for an authorized isolated lab. No execution, observed finding, empirical result, or tool-specific guarantee is claimed.

Актуально на: 2026-09-22. Статус: reviewed — правки сбрасывают статус рецензии. Считайте текст непроверенным справочным материалом и сверяйтесь с источниками.

Источники

Внешние источники не указаны; см. задокументированное основание выше.

Рецензия

Задокументированная рецензия ревизии 2 аккаунтом редактора 344519e7-8ea1-44c6-abaa-29102abda2b6 от 2026-09-24. Относится к текущей ревизии: да.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Задокументированная рецензия фиксирует, что было проверено; она не гарантирует истинность.

Атрибуция и лицензия

Последнее изменение: Initial original methodology; unreviewed.

Оригинальный материал: CC BY 4.0. Материалы по ссылкам сохраняют собственные права.