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
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
# Authz
## 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`?
## Permissions
Q: What permissions do each of the standard roles have today?
Q: Are there permissions that do not cascade down the group hierarchy?
## Scope
Q: How do we define the scope of a permission? (hierarchical?)
Current:
Desired:
| 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": [
"gid://app/Organization/1/Group/1/Project/1/*",
"gid://app/Organization/1/Group/1/Project/2/*",
"gid://app/Organization/1/Group/2/Project/3"
]
}
```
## 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)
Assigns permissions to roles, which are collections of permissions related to specific job functions.
This style of access control aligns with how humans organize themselves within
organizations by assigning job functions to roles. This model is simple and
aligns well with how humans operate within their job function.
This model also helps to align security objectives with higher level
organizational policy (.e.g. ethics, privacy, administration). This type of
model requires centralized control and enforcement.
> The act of granting membership and specifying transactions for a role is loosely
> analogous to the process of clearing users (granting membership) and the
> labeling (associate operation sensitivities) of objects ... - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
> A role can be thought of as a set of transactions that a user or set of users
> can perform within the context of an organization. - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
Roles are group oriented and they provide a means of naming and describing
many-to-many relationships between individuals and rights.
1. For each subject, the active role is the one that the subject is currently using:
```
AR(s: subject) = { the active role for subject s}.
```
2. Each subject may be authorized to perform one or more roles:
```
RA(s: subject) = { authorized roles for subject s }.
```
3. Each role may be authorized to perform one or more transactions:
```
TA(r: role) = { transactions authorized for role r}.
```
4. Subjets may execute transactions. The predicate `exec(s,t)` is true if
subject `s` can execute transaction `t` at the current time, otherwise it is
false:
```
exec(s :subject, t: tran) = true iff subject `s` can execute transaction `t`
```
Three basic rules are required:
1. Role assignment: A subject can execute a transaction only if the subject has
selected or been assigned a role
2. Role authorization: A subject's active role must be authorized for the
subject
3. Transaction authorization: A subject can execute a transaction only if the
transaction is authorized for the subject's active role
Another user of RBAC is to support integrity. One aspect of integrity is a
requirement that data and processes be modified only in authorized ways by
authorized users.
The problem of determining whether data have been modified only in authorized
ways can be as complex as the transaction that did the modification. For this
reason, the practical approach is for transactions to be certified and
trusted. If transactions must be trusted then _access control can be incorporated
directly into each transaction_.
#### See also
* [Role-Based Access Controls](https://csrc.nist.gov/files/pubs/conference/1992/10/13/rolebased-access-controls/final/docs/ferraiolo-kuhn-92.pdf)
### Relationship-Based Access Control (ReBAC)
### Attribute-Based Access Control (ABAC)
|
