Relationship Based Access Control in IoT and User Managed Access
Relationship Based Access Control (ReBAC) models originate from access control considerations made for Online Social Networks (OSN). In original ReBAC studies User-to-User (U2U) relations determine the access control decision made whenever a user (accessor) tries to access a resource. Policies typically evaluate the type, depth and strength of the U2U relation between the accessor and the resource owner (see Fong et al, Carminati et al).
Example: The friend of my friend has access to the picture that I posted.
Considering only U2U relations implicitly assume an “owns” relationship between resource and user. Access rights to the resource are determined by the U2U relation between the accessor and the owner. Other use cases in OSNs exist in which U2U relations are not sufficient and User-to-Resource (U2R) relations need to be considered (see Sandhu et al)
Example: The commenter of a blog entry might be allowed to contact another commenter of the same blog entry.
These expanded ReBAC models require U2U relationships (e.g. friend, parent, child) and U2R relationships (e.g. like, commented, tag). The relation “user commented on a blog entry” constitutes a U2R relation between the commenter and the blog post. The relation between two commenters of the same blog entry is a 2-hop U2R relationship.
Deriving access control decisions require policies (e.g. only direct friends are allowed to comment on my posting). In the context of OSNs it is assumed that many resource objects (pictures, postings) exist and have similar access policies. There are only few relation types (typically friend) and/or user groups (e.g. circles, friend lists). With that in mind a few policies are sufficient to represent access controls to many objects.
In case of the Internet of Things (IoT) access control need to be more granular. There is a need to have many more relation types between identities (U2U) and policies which govern the access to resources. A model as used for OSN would be very complex and policies would be very difficult to overlook and manage. Typically, this approach would lead to a vast growth of relation types and policies. Something similar to what we already know as role explosion from RBAC.
The aspects described above led us to another way of looking at ReBAC. We started to model the permissions directly as relations (edges) into the graph and reduced the number of policies to a single policy which basically says that an identity is allowed to access a resource if a path of a specific type between the identity and the resource exists.
Example: The delegate of a user with access permission to a third party resource has access to that resource as well
The policy evaluation function is:
F(A, R, P) = {0, 1}
with A = Accessing Identity, R = Resource, P = minimum permission type, {0,1} = the deny or permit decision
Under this model permissions are described as U2R relations and can then easily evaluated using Graph traversal algorithms.
To take the model even further we introduced access requests as U2R relations to represent User Managed Access (UMA) scenarios. The relation “read access requested” is converted to a “read access allowed” relation as soon as the resource owner approves the request.
Register with SSOCircle and get a real impression on ReBAC and MyIdentityGraph.