At its core, ReBAC is about granting access based on relationships. It's right there in the name: relationship-based access control. This means that policies are defined around the relationships between entities, such as a user owning a document. Relationships include data ownership, parent-child relationships, groups, and hierarchies.
The term ReBAC was coined in 2007 by Carrie Cates, in her paper Access Control Requirements for Web 2.0 Security and Privacy.
How ReBAC fits in with other access control models
Other access control models, such as role-based access control (RBAC) or attribute-based access control (ABAC), focus on user roles or attributes to determine access permissions. ReBAC, on the other hand, emphasizes the relationships between entities. The relationships create paths that can then be traversed to determine access. ReBAC is generally implemented on top of graph-based technologies. A great example of this is NIST’s NGAC (next-generation access control).
Another popular example of ReBAC is Zanzibar, a model popularized by Google in a seminal paper published at the 2019 USENIX Annual Technical Conference.
In ReBAC, the relationships themselves become a crucial part of the access control decision-making process.
ReBAC, RBAC, and ABAC are not mutually exclusive. ReBAC can leverage an existing RBAC infrastructure. For instance, rather than assigning ownership to a specific user, we can assign ownership to a role. For instance, the sales manager can view documents in the sales folder. The fact Alice is a sales manager is maintained by the RBAC solution which can now focus nearly exclusively on the identity management side of things.
ABAC, too, has its own place. ReBAC is limited to “static” relationships and cannot easily handle context or more advanced conditions. This is where attributes and a policy language to combine them comes into play. Imagine, for instance, you want to let a user delete a document they own but only if it’s not published. ReBAC alone cannot give you access to the document publication status. For that, you need attributes and a language. OpenFGA, as an example, uses Google CEL to express such conditions.
If starting from an ABAC framework such as an ALFA-based authorization solution, one can leverage ReBAC by connecting to an external attribute source that is ReBAC or graph-based. One of the key benefits of this approach is that the policy becomes (or remains) your main configuration artifact. Policies are easier to read, write, test, and audit than graphs.
Most policy languages can express relationships:
- A direct relationship such as ownership or parent-child. A user can view a document they own.
- An indirect relationship such as through a common attribute (e.g. a user can view a document if the user is in the same department as the document).
namespace relationships {
policy viewDocument{
target clause actionId == "view" and objectType == "document"
apply firstApplicable
rule owner{
permit
condition user.name == document.owner // direct relationship
}
rule sameDepartment{
permit
condition user.department == document.department // indirect relationship
}
}
}Implementing ReBAC
When it comes to implementing ReBAC, there are different approaches and considerations:
Policy language
The policy language used for ReBAC should support expressing relationships effectively. This may involve extending the language to include data types like JSON or tuples to represent relationships as first-class citizens.
Graph-based authorization
Some ReBAC implementations use graph databases to represent and query relationships between entities. This allows for efficient traversal and evaluation of complex relationship structures.
Tuples
Another approach is to represent relationships as tuples, which are ordered lists of elements. Tuples can capture the entities involved in a relationship and any associated metadata.
Schema and authorization
In some ReBAC implementations, the schema itself can carry authorization meaning. This blurs the line between configuration and authorization, as the schema definition becomes part of the access control decision-making process.
The benefits of combining ReBAC and ABAC
ReBAC alone gives a strong foundation to express, store, and maintain relationship data. Combined with ABAC and a policy-driven approach, it offers several benefits:
Fine-grained access control
Policies implementing a ReBAC approach allow for more granular access based on specific relationships between entities.
Context-aware authorization
By leveraging additional attributes, ReBAC can take into account the context in which access requests are made. This allows for more dynamic and adaptable access control decisions.
Flexibility and expressiveness
ReBAC provides a flexible and expressive way to define access control policies. It can handle complex relationship structures and capture nuanced authorization requirements.
Using ABAC together with ReBAC helps both scale. For instance, when implementing an indirect relationship (e.g. permit access if the user and the document are in the same department), in ABAC the policy holds true no matter how many departments you have. You can add, remove, split your HR, Engineering, Sales departments and the policy will still work as expected. In contrast, an RBAC system would have to be updated to cater to the new departments (or to deprovision access previously granted to former departments).
Implement ReBAC with Axiomatics
Axiomatics understands that at the heart of ReBAC lies the need to grant access based on relationships between users and resources. Axiomatics goes beyond ReBAC, letting users benefit from relationships but also additional constructs.
While relationships play a crucial role, other attributes such as location, time, and context also influence access decisions. Our hierarchical policy structure enables you to incorporate diverse attributes seamlessly, ensuring comprehensive access control that aligns with your requirements, no matter how unique. Policies also help establish a clear order of execution and precedence. Policies can also be used to restrict or constrain access that would otherwise be naturally granted via ReBAC alone.