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
|
# 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. [1]
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.
Unlike [RBAC][4] and [ABAC][3], ReBAC policies deal with relational policies
rather than unary predicates on attributes and roles.
In, Online Social Network (OSN) applications, authorization for users' access to
specific content is typically based on ther interpersonal relationships between
the accessing user and content owner. OSN ReBAC models user user-to-user
relationships.
The user of indirect relations, also called multilevel or composite relations,
is fundamental to ReBAC (e.g. friend of friend).
Recently, researchers have proposed extended ReBAC models applicable to other
computing systems beyond OSNs.
Most ReBAC models consider `user-to-user` and possibly `user-to-resource`
relationshps. Very few consider `resource-to-resource` relationships. Models
that consider `resource-to-resource` relationships typically do so through
users.
## Access Control Policies
Let `U` be the set of all users in the system.
Accesses are directed against resources. A resource may represent one or more
objects or certain system operations. Let `R` be the set of resources protected
by the SNS. A typical member of `R` is denoted by `r`.
Assocated with every access request are therefore the following:
* a protected resource that is being accessed
* the owner of that resource
* the accessor of that resource who requests access.
Owner of a resource implies that the accessor must be in a specific kind of
relationship with the owner in order be granted. Huh?
Associated with every resource is an `access control policy`.
Policy is modeled as a ternary predicate: `U x U x G(U, I) => {0, 1}`.
## Protection System
A protection system `N` is a 7-tuple `(I, U, R, C, C0, policy, owner)` where:
* `I` is the set of relation identifiers (See my question in the README about resource identifiers in our system)
* `U` is a finite set of users in the system
* `R` is a finite set of resources to be protected by the system.
* `C` is a _infinite_ universe of `access contexts`.
* `C0` is the root context. (* Could this be the root `Organization` that a `User` belongs to?)
* `R => PP(U, I)` assigns a policy predicate to every resource in the system. (This means that every resource is addressable through a universal identifier, right? Goodbye `bigint`? Yay!)
* `owner: R -> U` is a function that assigns an owner to every resource in the system.
Where the access control policy of a resource comes from doesn't matter. The
possibilities are:
1. Mandatory: Some policies are mandated by the system administrator
1. Discretionary: The resource owners are responsible for specifying their
access control policies
1. Policy Vocabulary: A set of policy predicates from which users take their
picks. (friends, friends-of-friends)
## Protection State
Given a protection system `N = {I,U,R,C,C0,policy,owner}`, a protection state is
a triple `{C,sn,extends}` composed of the following elements:
* `C`: is the set of active contexts in the state. This set is infinite and
non-empty.
* function `sn : C -> G(U,I)` that maps each context of the state to a social
network `sn(s)` records the relationships that have been articulated in
context `c`.
* `extends ~= C x C` is a binary relation defined over `C`, such that:
* a: the directed graph is a tree
* b: `c0` is the root of the tree
* c: if `(c1,c2) ~= extends` then `c1` is the child of `c2` in the tree. The
extends relationship defines a **context hierarchy**.
## Authorization
Authz is achieved by consulting relationships in a social network. Authorization
decisions are made primarily by consulting the relationship between accessor and
the owner. In a real implementations, it is possible for the system to have a
hybrid authorization scheme that is both relationship based and role based.
Relationship inheritance allows relationships articulated in ancestor contexts
to be inherited by the effictive social network of descendant contexts. The
social network of a child context contains no less relationships than that of a
parent context.
## Policy Language
It is desirable to have a [policy language](./POLICY.md) for specifying ReBAC policies.
A policy language facilitates:
1. the specification of composite policies, which in turn forms the basis of trust delegation.
1. **the static analysis of policies and system configuration.**
## Context Hierarchy
The context hierarchy assumes a tree shape: i.e., only single inheritance is permitted.
Multiple inheritance corresponds to a more flexible means of constraining when
relationships can be "activated" simultaneously.
## Conclusion
>Relationship-Based Access Control works best in application domains in which
>binary relations are more natural for expressing authorization decisions than
>unary relations (e.g., roles).
## See also
* [Relationship-Based Access Control: Protection Model and Policy Language by Philip W. L. Fong][1]
* [Learning Relationship-Based Access Control Policies from Black-Box Systems][2]
* [Classifying and Comparing Attribute-Based and Relationship-Based Access Control][5]
[1]: https://cspages.ucalgary.ca/~pwlfong/Pub/codaspy2011.pdf
[2]: https://dl.acm.org/doi/pdf/10.1145/3517121
[3]: ./ABAC.md
[4]: ./RBAC.md
[5]: https://dl.acm.org/doi/pdf/10.1145/3029806.3029828
|
