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
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
# 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)
> Authorization decisions are based on the relationship between the resource owner
> and the resource accessor in a social network maintained by the protection
> system.
A Social Network System (SNS) maintains a social network for at least two reason:
1. It is used by the users to navigate the information space of the system
2. The social network is used as a basis for formulating the access control
policies of user contributed resources.
Access Control Paradigm:
1. the explicit tracking of one or more social networks by the protection system
1. the expression of access control policies in terms of the relationship
between the resource owner and the resource accessor
Suited for domains in which relationship and authorization decisions are from
the structure of trust that is inherent in the application domain rather than
subjective assessment of users.
It is more natural to base authz decisions on whether the resource owner and
accessor are in a particular kind of relationship.
In a standard RBAC system, when a permission `p` is assigned to role `R`, we are
essentially formulating the following policy: `grant p to user u if R(u)`.
PriMA is another recently proposed privacy protection mechanism for SNSs.
References
* [Relationship-Based Access Control: Protection Model and Policy Language by Philip W. L. Fong](https://cspages.ucalgary.ca/~pwlfong/Pub/codaspy2011.pdf)
### Attribute-Based Access Control (ABAC)
|
