Building ReBAC Policies

Relationship-Based Access Control (ReBAC) policies determine access based on the relationships between users and resources. Constructing ReBAC policies involves defining these relationships and specifying the associated permissions.

Before you start

Before you begin molding your own ReBAC policy within Permit, it's essential to establish a clear understanding of the various relationships that exist within your system, as these will form the core of your policy. Identify the key subjects (users or entities) and objects (resources) and how they interact with each other, mapping out both direct and indirect relationships.

Consider the nature of these relationships, whether hierarchical, peer-to-peer, or something more complex. You should also have a grasp of the specific permissions that correspond to different relationships, and a thorough understanding of the overall system architecture.

Having a well-defined set of roles and attributes for both subjects and objects can further refine the policy. Assessing these prerequisites and having a detailed understanding of the relationships within your system ensures a robust and effective ReBAC policy that aligns with your organization's needs and security requirements.

Using the policy editor to create ReBAC enforcements

The Permit policy editor is very flexible for creating all types of policies, including policies as complex as ReBAC. With ReBAC, we're going to map out not just the roles, but also how they interact with each other and the resources they access.

Creating resources

Resources are the fundamental entities that users interact with. Whether it's a folder, a module, or a project, identifying and categorizing these resources is the first step to establishing a permissions framework.

UI Example

Create resource relationships

Relationships determine how different resources are connected or related to each other. By defining relationships, we can create a structured hierarchy or network, enabling more granular control over access permissions based on these connections.

UI Example

info

Once you successfully define the relationships on the roles - it will automatically create the roles for you in the policy editor.

Adding roles to resources

By associating roles with specific resources, we can determine what actions or levels of access a user or group of users can have with those resources. It forms the crux of ReBAC, ensuring that permissions are not just based on user identities, but their roles concerning various resources.

UI Example

Defining role derivations

Role derivation allows for the dynamic assignment or inheritance of roles based on certain conditions or relationships. This step ensures flexibility in the ReBAC system, allowing roles to be contextually derived based on factors like a user's relation to a resource.

UI Example

Creating a resource instance

A resource instance is a specific occurrence or version of a resource. While document is a resource, Document A or Version 2 of Document A are its instances. Recognizing and differentiating these instances is crucial for pinpoint access control.

Assigning resource instances to a user

This final step ties everything together by associating a specific resource instance with a user, based on their role. This assignment ensures that users have the correct access to resources in the context of their roles, solidifying the principles of ReBAC.

UI Example

Enforcing your policies in your code

In the context of Role-Based Access Control (ReBAC), the enforcement of permissions becomes more granular and contextual. Instead of merely assigning permissions based on a user's static role, ReBAC looks at the relationships and interactions between users, their roles, and the resources they want to access.

Here is a code snippet showing an enforcement being made, checking if a user can be assigned to a specific member group.

await permit.check(userId, "assign", `member_group:${group}`);

can be broken down and understood in the following manner:

Function: permit.check()

This function, as its name suggests, is used to check if a specific user has the necessary permissions to perform a particular action on a given resource.

Parameters:

userId

This represents the unique identifier for the user whose permissions are being checked.

assign

This is the action that the user wishes to perform. In this case, the user wants to "assign" a member to a group.xe

member_group:${group}

This is the resource upon which the user wishes to perform the action. It's formatted as a template string to allow for dynamic insertion of the group's resource instance.