You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: coderd/authz/README.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -58,7 +58,7 @@ This can be represented by the following truth table, where Y represents *positi
58
58
59
59
A *role* is a set of permissions. When evaluating a role's permission to form an action, all the relevant permissions for the role are combined at each level. Permissions at a higher level override permissions at a lower level.
60
60
61
-
The following table shows the per-level role evaluation.
61
+
The following table shows the per-level role evaluation logic.
62
62
Y indicates that the role provides positive permissions, N indicates the role provides negative permissions, and _ indicates the role does not provide positive or negative permissions. YN_ indicates that the value in the cell does not matter for the access result.
This approach is problematic because of the cardinality of the RBAC model.
44
-
45
37
Recall that the legacy `pkg/access/authorize`:
46
38
- Exposes 8 possible actions, 5 possible site-level roles, 4 possible org-level roles, and 24 possible resource types
47
39
- Enforces site-wide versus organization-wide permissions separately
48
-
49
40
The new authentication model must maintain backward compatibility with this model, whilst allowing additional features such as:
50
41
- User-level ownership (which means user-level permission enforcement)
51
42
- Resources shared between users (which means permissions granular down to resource IDs)
52
43
- Custom roles
53
-
54
44
The resulting permissions model ([documented in Notion](https://www.notion.so/coderhq/Workspaces-V2-Authz-RBAC-24fd193386eb4cf79a282a2a69e8f917)) results in a large **finite** solution space in the order of **hundreds of millions**.
55
-
56
45
We want to have a high level of confidence that changes to the implementation **do not have unintended side-effects**.
57
46
This means that simply manually writing a set of test cases possibly risks errors slipping through the cracks.
58
-
59
47
Instead, we generate (almost) all possible sets of inputs to the library, and ensure that `authz.Authorize` performs as expected.
60
-
61
48
The actual investigation of the solution space is [documented in Notion](https://www.notion.so/coderhq/Authz-Exhaustive-Testing-7683ea694c6e4c12ab0124439916b13a), but the crucial take-away of that document is:
62
49
- There is a **large** but **finite** number of possible inputs to `authz.Authorize`,
63
50
- The solution space can be broken down into 9 groups, and
64
51
- Most importantly, *each group has the same expected result.*
65
-
66
52
## Testing Methodology
67
-
68
-
69
53
We group the search space into a number of groups. Each group corresponds to a set of test cases with the same expected result. Each group consists of a set of **impactful** permissions and a set of **noise** permissions.
70
-
71
54
**Impactful** permissions are the top-level permissions that are expected to override anything else, and should be the only inputs that determine the expected result.
72
55
**Noise** is simply a set of additional permissions at a lower level that *should not* be impactful.
73
-
74
-
For each group, we take the **impactful set** of permissions, and add **noise**, and combine this into a role.
75
-
56
+
For each group, we take the **impactful set** of permissions, and add **noise**, and combine this into a role.
76
57
We then take the *set cross-product* of the **impactful set** and the **noise**, and assert that the expected access level of that role to perform a given action.
77
-
78
58
As some of these sets are quite large, we sample some of the noise to reduce the search space.
79
-
80
-
TODO: example.
81
-
82
-
## Permission Permutations
83
-
59
+
**Example:**
60
+
`+site:resource:abc123:create` will always override `-user:resource:*:*`, `-user:*:abc123:*`, `-org:resource:*:create`, and so on. All permutations of those sorts of noise permissions should never change the expected result.
61
+
## Role Permutations
84
62
Recall that we define a permission as a 4-tuple of `(level, resource_type, resource_id, action)` (for example, `(site, workspace, 123, read)`).
85
-
86
63
A `Set` is a slice of permissions. The search space of all possible permissions is too large, so instead this package allows generating more meaningful sets for testing. This is equivalent to pruning in AI problems: a technique to reduce the size of the search space by removing parts that do not have significance.
87
-
88
-
This is the final pruned search space used in authz. Each set is represented by a Y, N, or _. The leftmost set in a row that is not '_' is the impactful set. The impactful set determines the access result. All other sets are non-impactful, and should include the `<nil>` permission. The resulting search space for a row is the cross product between all sets in said row.
89
-
90
-
64
+
This is the final pruned search space used in authz. Each set is represented by a Y, N, or _. The leftmost set in a row that is not '_' is the impactful set. The impactful set determines the access result. All other sets are non-impactful, and should include the `<nil>` permission.
65
+
The resulting search space for a row is the cross product between all sets in said row. `+` indicates the union of two sets. For example, Y+_ indicates the union of all positive permissions and abstain permissions.
0 commit comments