main

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
  2. 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 and ABAC, 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
  2. Discretionary: The resource owners are responsible for specifying their access control policies
  3. 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 for specifying ReBAC policies.

A policy language facilitates:

  1. the specification of composite policies, which in turn forms the basis of trust delegation.
  2. 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