blob: b750481e675cc1d2cb12c7f29ba2811654c4868a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
# Authz
## Access Control Models
Access Controls provide a means of restricting access to objects based on the
identity of subjects and/or groups to which they belong.
* Role-Based Access Control ([RBAC](./RBAC.md))
* Relationship-Based Access Control ([ReBAC](./ReBAC.md))
* Attribute-Based Access Control ([ABAC](./ABAC.md))
## Policy
* [What is a policy?](./POLICY.md)
* Policy Language Evaluation
* Zanzibar
* [Dafny](https://dafny.org/)
* Cedar
* Casbin
Criteria for evaluating policy languages:
* Must be able to model different types of access control models (RBAC, ReBAC, ABAC)
* Must be able to perform static analysis
* Must be well supported
* Must have concise documentation
* Must provide ability to extend language using Ruby/Golang for describing complex policies.
## Organizational Hierarchy
How does a permission cascade down a group hierarchy?
```
Organization
Group A
* Roles
* Developer
* Maintainer
* Custom A
* base: developer
* permissions:
* admin_vulnerability: true
* read_vulnerability: true (implicitly)
* Custom B
* base: maintainer
* permissions:
* Doesn't really matter because Maintainer has all the permissions available via a custom role. <- Fact check this
Group Aa
Project Aa1
Project Aa2
Group Aaa
Project Aaa1
Project Aaa2
```
If a user has a membership at `Group A`, does the permissions associated with that
membership cascade down to `Group Aa` and `Group Aaa`?
## Scope
1. Single resource
1. Nested resources
1. Individual Attributes on a resource
### Current:
### Desired:
#### Option 1
| permission | scope | description |
| ---------- | ----- | ----------- |
| `read` | `gid://app/Organization/1` | Can read Org 1 resource |
| `read` | `gid://app/Organization/1/*` | Can read every resource below Org 1 hierarchy |
| `read` | `gid://app/Organization/1/Group/1` | Can read Group 1 resource |
| `read` | `gid://app/Organization/1/Group/1/*` | Can read every resource below Group 1 hierarchy |
| `read` | `gid://app/Organization/1/Group/1/Project/1` | Can read project 1 |
| `read` | `gid://app/Project/1` | Can read project 1 resource (short circuit example) |
| `read` | `gid://app/Organization/1/Group/1?attributes[]=name&attributes[]=description` | Can read name and description of Group 1 resource |
Example:
The following example allows the subject of the token to read all of the descendant resources of `Project 1` and `Project 2` and it can read `Project 3`.
```json
{
"sub": "gid://User/17",
"scope": {
"read": [
"gid://app/Organization/1/Group/1/Project/1/*",
"gid://app/Organization/1/Group/1/Project/2/*",
"gid://app/Organization/1/Group/2/Project/3"
]
}
}
```
#### Option 2
Encode access and scope directly into the name of the permission.
| permission | description |
| ---------- | ----------- |
| `read:organization:1` | Can read Org 1 resource |
| `read:organization:1:*` | Can read every resource below Org 1 hierarchy |
| `read:organization:1:group:*` | Can read Group 1 resource |
| `read:organization:1:group:1:*` | Can read every resource below Group 1 hierarchy |
| `read:organization:1:group:1:project:1` | Can read project 1 |
| `read:project:1` | Can read project 1 resource (short circuit example) |
| `read:organization:1:group:1:attributes[]=name&attributes[]=description` | Can read name and description of Group 1 resource |
Example:
```json
{
"sub": "gid://User/17",
"scope": [
"read:organization:1:group:1:project:1:*",
"read:organization:1:group:1:project:2:*",
"read:organization:1:group:2:project:3"
]
}
```
|
