Role-Based Access Control (RBAC): Ultimate Enterprise Guide

Table of Contents

• Introduction
• What is Role Based Access Control (RBAC)?
• How RBAC Works?
• Benefits of Role-based Access Control
• Drawbacks of RBAC
• Types of Roles in Authorization Models
• Best Practices for Defining Roles in RBAC?
• How do Models in RBAC Work?
• Alternative Access Control Models
• When RBAC is Needed?
• Managing Role Escalations and De-escalations Effectively in RBAC
• What Tools and Software Support RBAC Management?
• Common Challenges and Solutions in RBAC Implementation
• How to Implement an Role Based Access Control (RBAC)?
• Summary

Introduction

Effective access management is crucial for any organization; it makes it possible to efficiently control and streamline user access and permissions to different systems and their underlying resources.

While authentication systems are an essential security step they don't control what they can do once logged in.

Failing to manage user access and permission rights properly can have severe consequences, such as granting unauthorized individuals access to sensitive data, critical applications, as well as compromising the integrity of the organization's systems.

Role-Based Access Control (RBAC) is an traditional approach to access and permissions management. RBAC systems allow you to specify, group, and grant permissions to individuals based on their organizational position, authority, roles, and responsibilities.

In this guide, we'll cover everything you need to know about implementing RBAC for your applications. We'll start by exploring the fundamentals of RBAC and the situations where it's most effective.

We'll also highlight tools and software that support RBAC management, common challenges and solutions in RBAC implementation, as well as how to implement a successful RBAC system.

Let's get started!

What is Role Based Access Control (RBAC)?

Before we dive into the specifics of role-based access control (RBAC), let's explore some basics first. What essentially is access control?

Ideally, access control is simply a system of checks and balances that regulates how different users interact with various applications and resources within an organization.

It dictates what information they can see, what actions they can take, and ultimately, the level of control they have.

This is achieved by defining clear rules that assign specific permissions to different users and groups of users. These permissions determine the precise actions a user can perform within a system.

Among various access control systems (there are several which we'll explore) role-based access control (RBAC) is widely used.

RBAC is an authorization system that governs access to applications, system resources, and data by associating permissions with predefined roles within an organization. These roles are carefully designed to reflect the hierarchical structure of the organization.

Implementing RBAC involves several key processes:

• Role Assignment: This step involves assigning a specific role to a user or groups of users e.g. a particular department, effectively granting them the associated permissions.

• Role Mapping: This step establishes the critical relationships between roles and permissions. It defines exactly which permissions are associated with each role. This ensures that users assigned to a particular role receive the necessary access rights to perform their tasks, without granting them unnecessary access to other functionalities or data.

• Role Authorization: This step involves verifying whether a user's assigned role grants them the necessary permissions to perform a particular action within a system. It ensures authorized access and prevents unauthorized actions.

• Role Revocation: As employees' roles and responsibilities within an organization change over time, it becomes crucial to promptly adjust or revoke roles that are no longer required or relevant.

  This process is particularly important when employees leave the organization or transition to new roles with different access requirements. Revoking unnecessary roles helps maintain a robust security posture by ensuring that users only have access to the specific permissions they currently need to perform their job functions.

• Role Hierarchy: RBAC often utilizes a hierarchical structure. In this structure, higher-level roles inherit permissions from lower-level roles. This simplifies role management by reducing the need for redundant permission assignments.

Now that we’ve got a basic understanding of RBAC, let’s explore how it works in detail.

How RBAC Works?

Role-Based Access Control is particularly useful for larger enterprises with a significant number of employees, where administrators need to assign unique access rights to each individual.

With an automated RBAC system, administrators can create users and user groups, assign roles to them, and then allow access to a defined set of resources based on those roles.

This is done instead of assigning unique access rights to each individual user. This essentially culminates to having an access policy.

In essence, user access provisioning is based on the needs of a particular group, such as a department, considering their common job responsibilities and requirements.

For instance, you can have users who are administrators, specialists, or end-users, with access limited to specific resources or tasks. The idea is to have users inherit a set of permissions based on their assigned role or job function.

It's important to note that successful RBAC implementation requires careful planning. It is crucial to define permissions for each role in detail, considering actions like data creation, modification, or deletion within specific applications.

The goal is to strike a balance: providing users with the necessary permissions while minimizing the risk of unauthorized access.

Benefits of Role-based Access Control

RBAC offers numerous benefits that make it a highly effective access management approach.

Let's take a look at some:

• Easier management and reduced administrative burden: RBAC simplifies access management by replacing individual user permission assignments with pre-defined roles.

  RBAC allows you to efficiently manage access by assigning roles like "editor" or "accountant" that come with pre-defined permission sets.This not only saves IT teams valuable time but also reduces the risk of human error during permission assignment.

  Moreover, adding or changing roles becomes a breeze—simply update a user's role, and their access automatically adjusts across different systems and applications. This flexibility is ideal for managing employees, as well as third-party contractors.

• Compliance made easy: Meeting data privacy and protection regulations becomes easier with RBAC. By restricting access based on roles, you significantly reduce the risk of accidentally exposing sensitive information. This ensures stronger alignment with regulatory and statutory requirements for data confidentiality and privacy.

• Increased visibility and control: RBAC provides a clear picture of who has access to what resources within your organization. You can easily track resource usage and ensure everyone adheres to security protocols.

  This enhanced visibility helps maintain a secure and controlled environment. Auditing user privileges becomes a simpler task, allowing you to identify and promptly correct any access control issues.

• Aligns with zero trust security: RBAC aligns perfectly with the zero trust security approach, a model that assumes no user is inherently trusted.

  By granting users only the minimum permissions required for their tasks (least privilege), RBAC minimizes the risk of data breaches and leaks. This proactive approach is essential in the dynamic and ever-evolving security landscape.

• Improved Auditability: RBAC maintains clear audit trails by tracking user roles, permissions, and access attempts.

  This detailed record allows organizations to monitor user activity, identify suspicious behavior, and investigate potential security breaches more effectively. Furthermore, role-based access simplifies compliance audits by demonstrating a clear system for managing user access permissions.

• Separation of Duties: By assigning distinct roles with specific permissions, RBAC enforces separation of duties.

  This means critical tasks require the involvement of multiple users with different roles, preventing a single individual from having complete control over sensitive data or processes. This significantly reduces the risk of internal fraud or unauthorized modifications.

Drawbacks of RBAC

While RBAC offers significant benefits for access control, it's not without limitations.

Here are potential drawbacks to consider:

• Complexity for Large Organizations: RBAC excels in organizations with a well-defined structure and roles. However, in very large organizations with a vast number of users, roles, and resources, managing RBAC can become cumbersome.

  Maintaining a large role library and ensuring they all adhere to the principle of least privilege can be a significant administrative burden for IT teams.

• Limited Flexibility in Dynamic Environments: RBAC thrives on clear-cut roles and responsibilities. In fast-paced environments with evolving workflows and processes, RBAC may struggle to adapt.

  Creating new roles or modifying existing ones to accommodate changing needs can be a time-consuming process, hindering agility.

• The Threat of Role Explosion: As the number of users, resources, and access permissions within an organization grows, so can the number of roles required to manage them effectively.

  Ideally, this can potentially lead to role explosion, where the number of roles escalates to a point where access control becomes significantly more complex. An excessive number of roles can defeat the very purpose of RBAC—simplification.

• Potential for Errors: The success of RBAC hinges on clearly defined roles and accurate permission assignments. However, improperly defined roles or accidental assignment of incorrect permissions can create security vulnerabilities.

  Manually managing numerous roles increases the risk of human error, potentially granting unauthorized access to sensitive data or restricting legitimate users from performing their jobs effectively.

Now, let's explore some common roles you can define and use to implement your RBAC models.

Types of Roles in Authorization Models

RBAC, or any other authorization model, rely on roles to define user permissions and access control. These roles categorize users based on their responsibilities and functionalities within a system.

Here's a breakdown of some common types of roles you might encounter:

• Predefined Roles: These are pre-built roles with established permissions readily available within the system. They represent common functionalities across many organizations. Here are some examples:

  1. Administrator: The ultimate authority, with full access to all system resources. This includes adding/removing users, managing roles, and configuring settings.

     This role can further be categorized to admin and super admin, each having its own set of permissions depending on the intented use.

  2. Viewer: Limited to viewing and reading information.

  3. Auditor: Can access and review system logs and audit trails for security purposes.

• Business-Specific Roles: These roles are tailored to the unique needs and workflows of an organization, mapping to specific departments and functions. e.g. a marketing manager with permissions to manages marketing campaigns, create content, analyze marketing data, e.t.c.

• Hybrid Roles: These roles combine elements of both predefined and business-specific roles. They offer a more granular approach to access control by assigning permissions based on both generic functionalities, along with specific business needs.

• Temporary Roles: These roles are short-term assignments granted to users for specific tasks. They're ideal for situations requiring temporary access to resources or functionalities.

  A good example for this could be a "Project Editor" role with access limited to the duration of a specific project or third-party contractors working on specified tasks.

• Dynamic Roles: These roles can adapt based on certain conditions or attributes associated with the user or system. Imagine a user's role changing based on their location, time of day, or completion of a specific task.

Best Practices for Defining Roles in RBAC?

Implementing RBAC within your organization is a significant undertaking that requires careful planning and consideration.

To ensure a smooth transition and minimize potential confusion or frustration among your team, it's essential to follow a structured approach.

Here are some best practices to consider before diving into the implementation:

• Analyze Existing User Permissions: Before creating new roles, understand the current access users have to resources like applications, software, and hardware. Map out the already existing user permission systems in place before doing a complete system redesign.

• Take advantage of Role Templates: Standardize user access by creating role-specific templates that assign permissions based on job responsibilities. This promotes consistency and efficiency.

• Maintain Audit Logs: Track all modifications to user roles, access rights, and permissions. This audit trail can help identify potential privilege abuses, detect suspicious activity, and uncover security vulnerabilities.

• Implement Least Privilege: Apply the principle of least privilege, ensuring users only have the minimum access necessary to perform their job duties. Define baseline permissions for each RBAC role.

• Establish Role-Based Policies: For each role, create clear policies outlining the associated permissions. This can include definitions for roles like administrator, regular user, and guest.

• Continually Adapt: RBAC is an iterative process, and it's essential to continually adapt and refine your approach. The initial implementation of RBAC will likely require some adjustments and tweaks.

  Be prepared to make necessary changes based on your findings, as RBAC is not a one-time setup but an ongoing process that should evolve as your organization's needs change.

• Thoroughly Test the RBAC Model: Evaluate the impact on user productivity and refine the role definitions accordingly. Always test roles in a staging environment before deployment.

How do models work? Let's find out.

How do Models in RBAC Work?

While the core RBAC concept revolves around roles, permissions, and users, there are several implementations that build upon this foundation to offer additional functionalities suited to various organizational needs.

Here's a closer look at these implementations in RBAC:

1.Basic RBAC

Basic RBAC forms the bedrock of all RBAC models. It establishes the core components:

• Users: These are the individuals or entities requiring access to the system.

• Roles: These represent job-like classifications within the organization. Each role groups specific permissions based on a particular function or responsibility (e.g., Editor, Marketing Manager). Users are assigned roles based on their job requirements.

• Permissions/actions: These define the specific actions a user can perform within the system, such as reading, creating, editing, deleting, or managing specific resources.

Access decisions are solely based on a user's assigned roles. The system checks the user's role against predefined permissions whenever they attempt to access a resource or perform an action.

Whenever a user attempts to access a specific resource, if the user's role has the necessary permission, access is granted. This streamlined approach simplifies access control management.

2. Hierarchical RBAC

Hierarchical RBAC builds upon the foundation of Basic RBAC by introducing a concept called role hierarchy. This creates a structure where senior roles inherit permissions from junior roles within the hierarchy.

Imagine a pyramid structure with more general roles at the base and more specific roles at the top. Roles higher in the hierarchy inherit all the permissions of the roles below them.

This approach offers several advantages:

• Simplified Permission Management: Administrators only need to define permissions at the lower levels of the hierarchy. Senior roles automatically inherit these permissions, reducing the administrative burden.

• Reflects Real-World Authority Structures: The hierarchical structure can mirror real-world organizational structures, where senior roles have broader access compared to junior roles.

3. Constrained RBAC

Constrained RBAC adds an extra layer of security by incorporating Separation of Duties (SoD) principles. SoD ensures that critical tasks requiring multiple steps are not performed by a single user. This mitigates the risk associated with a single person having excessive control or malicious intent.

Essentially, constraints are defined within the RBAC model to prevent users from being assigned roles that grant conflicting permissions.

For example, a user cannot be assigned roles for both approving financial transactions and processing those transactions. This enforces a multi-user approach for sensitive tasks, reducing the risk of fraud or errors.

4. Symmetric RBAC

Symmetric RBAC offers the most flexibility among RBAC models. It extends the basic model by allowing permissions to be assigned to roles dynamically. This means that permissions can be added or removed from roles based on specific conditions or attributes associated with the user or the system.

Symmetric RBAC allows permissions to be dynamically assigned to the user's role based on changing attributes, such as time, tasks, role, location, e.t.c.

This approach provides granular control over user access and can be particularly useful in environments with frequently changing user needs or security requirements.

Here's a summarized comparison of these RBAC implementations:

It's important to develop a comprehensive grasp of these different RBAC models and their respective strengths.

This will make it more efficient to assess and choose the model that best aligns with their specific security posture, user base complexity, and desired level of access control granularity.

Alternative Access Control Models

While RBAC is a popular choice, several other access control models exist, each with its strengths and use cases.

Let's explore some of these models in detail:

1. Discretionary Access Control (DAC)

In the DAC model, the owner of a resource has the discretion to determine who can access it and what actions they can perform. This model follows the principle of least privilege, where users are granted only the minimum permissions required for their tasks.

DAC is commonly used in file permissions in operating systems and access control lists (ACLs) in enterprise applications.

2. Attribute-Based Access Control (ABAC):

ABAC is a more flexible and dynamic access control model that grants permissions based on a combination of attributes, such as user characteristics, resource properties, and environmental conditions.

Access decisions are made by evaluating these attributes against predefined policies. ABAC is used in cloud-based applications, Internet of Things (IoT) devices, and advanced enterprise applications.

Here is a table comparing the key differences between RBAC, ABAC, and DAC access control models:

The key differences lie in the basis for access decisions, the approach to policy definition, the level of granularity, and the overall flexibility and scalability of each model.

You should choose the access control model (or a combination of models) that best fits their security requirements, organizational structure, and operational needs.

When RBAC is Needed?

While RBAC can be beneficial in a variety of organizational settings, there are some general scenarios where RBAC is particularly well-suited:

• Large and Complex Organizations: RBAC is especially useful in large enterprises with a sizable workforce and a complex organizational hierarchy. It simplifies the management of access rights at scale.

• Regulated Industries: Organizations operating in highly regulated industries, such as healthcare, finance, or government, often need to comply with strict data privacy and security regulations. RBAC helps these organizations meet compliance requirements by ensuring appropriate access controls are in place.

• Dynamic Environments: In environments where job roles and responsibilities frequently change, RBAC provides the flexibility to quickly update access permissions by modifying the associated roles, rather than managing individual user access.

Managing Role Escalations and De-escalations Effectively in RBAC

Properly managing role escalations (expanding user permissions) and de-escalations (reducing user permissions) is crucial for maintaining a secure and efficient RBAC environment.

Why is this important? Imagine a scenario where a user's job responsibilities change, and they no longer require the same level of access to certain resources. If the user's permissions are not promptly de-escalated, they could retain unnecessary access, increasing the risk of data breaches, unauthorized modifications, or even internal fraud.

Similarly, if a user needs to take on additional responsibilities, their permissions may need to be escalated to allow them to perform their new tasks. Failing to do so in a timely manner can hinder productivity and frustrate employees.

Here are some best practices for managing role escalations and de-escalations in an RBAC system:

• Establish clear governance processes: Implement a well-defined governance framework that outlines the procedures and approvals required for role changes.

  Clearly define the roles and responsibilities of stakeholders involved in reviewing and approving role escalations and de-escalations. Ensure that all role changes are properly documented and audited for compliance and security purposes.

• Establish clear change policies and approval workflows: Develop a structured change management workflows to handle role changes, including impact analysis, approval workflows, and communication plans.

• Automate the process: Automate the role escalation and de-escalation process as much as possible. This can include integrating with HR teams or alternatively, identity management systems to trigger permission changes when a user's job role changes.

• Conduct periodic role reviews: Regularly review and recertify user roles and associated permissions to ensure they align with the user's current job responsibilities.

  Make sure to promptly revoke or adjust permissions for users whose roles have changed or who have left the organization.

• Just-in-Time provisioning: Implement a just-in-time provisioning approach. This means granting users the necessary access only when required for a specific task or project. This minimizes the risk associated with elevated privileges.

These strategies will help you achieve a secure and compliant access control environment, while still, ensuring users have the necessary access to access resources to interact with the systems.

What Tools and Software Support RBAC Management?

Implementing and managing RBAC effectively can be challenging, especially for larger organizations with numerous users, roles, and resources. There are various tools and software solutions that you can use to simplify and automate the process. They include:

• Identity and Access Management (IAM) Systems: Comprehensive IAM solutions offer a centralized platform for managing user identities, access controls (including RBAC), and authentication. These tools often provide features like user provisioning, role-based access configuration, and audit log management. Examples include:
  1. Microsoft Entra ID.
  2. Oracle Identity Management.

Read More: Top 6 Open Source IAM Solutions For Enterprises

• Security Information and Event Management (SIEM) Systems: SIEM tools collect and analyze security data from various sources, including user activity logs generated by RBAC systems. This allows for comprehensive monitoring of user access attempts, identification of suspicious behavior, potential security breaches, and much more. Examples include:

  1. IBM QRadar

• Custom-Developed Solutions: Organizations with highly specialized needs may opt for custom-developed RBAC solutions. These solutions offer maximum flexibility but require significant development resources and expertise to maintain. Examples:

Carefully consider your organization's specific needs and then evaluate the available RBAC management tools to select the one that best streamlines your access control processes.

Common Challenges and Solutions in RBAC Implementation

Implementing Role-Based Access Control (RBAC) within an organization can present several challenges.

Here are some common challenges and potential solutions to address them:

• Role Proliferation: Arguably, in any growing organization, the number of roles and associated permissions within an RBAC system is likely to expand over time as the business and its processes evolve.

  This natural role proliferation can quickly lead to an unwieldy number of roles, increasing the complexity of access management and potentially introducing security risks.

  For this reason, it's imperative to Implement a structured role management process, that includes processes to manage regular reviews and consolidation of roles. Ideally, you want to make sure you identify and eliminate redundant or unnecessary roles.

• Defining and Enforcing Separation of Duties: Ensuring the appropriate separation of duties (SoD) between roles is essential to mitigate the risk of fraud, errors, and unauthorized access. However, defining and enforcing SoD can be a complex process, especially if there's potential for roles overlap.

  To address this, you should develop a comprehensive SoD matrix that identifies incompatible roles and permissions. Moreover, implementing access controls and monitoring mechanisms further reinforces the enforcement of SoD policies.

• Aligning RBAC with Business Processes: Integrating RBAC with an organization's existing business processes and workflows can be a significant challenge, especially in mature organizations with complex operations.

  Conducting a thorough analysis of these processes and workflows is necessary to design an RBAC model that aligns with and supports the operational requirements. By doing so, you can ensure that the RBAC implementation seamlessly integrates with their existing systems, business processes, and procedures.

• Maintenance and Governance: Maintaining the RBAC model, reviewing roles and permissions, and ensuring ongoing governance is a continuous effort, especially in dynamic environments.

  While this might seem monotonous, it is essential to establish a dedicated RBAC governance protocol for managing the RBAC lifecycle, including role lifecycle management, access reviews, and policy updates, which can help you stay on top of this critical aspect.

Proactive strategies and a keen understanding of these common hurdles are important to effectively address and overcome them.

Continuously refining and adapting your RBAC strategies will inevitably lead to a more efficient and secure access control system that stands the test of time and evolves with the requirements.

How to Implement an Role Based Access Control (RBAC)?

As we have seen so far, implementing a Role-Based Access Control (RBAC) authorization model for any system necessitates a structured approach. First, it involves identifying and defining the roles that exist within the organization and will be adapted for the system.

Then, it requires specifying the permissions or access rights associated with each role. Finally, the implementation process culminates in mapping users to specific roles, granting them the corresponding set of allowed permissions.

Now, let's see how we can implement the same principles in code.

For example, in a content management system, you might have roles such as admin, creator, and so on. Once you have identified the roles, you can then proceed to define them in your application's code.

Typically, if you are building your backend apps with Express.js, you could define and implement RBAC in the following way, although the specific implementation might vary, the focus points will be more or less the same.

First, you will define roles as an object:

const roles = {
  ADMIN: 'admin',
  CREATOR: 'creator'
}

Next, you need to define the permissions associated with each role, mapping roles to their respective permissions. For example:

const permissions = {
  [roles.ADMIN]: ['edit', 'delete'],
  [roles.CREATOR]: ['write'],
}

In this example, admins have full access to edit and delete, while creators can only write content.

Finally, you need to map users to their respective roles. This can be done by storing user roles and permissions in a database like MongoDB or a relational database like PostgreSQL.

Here's a sample Mongoose schema for storing roles and permissions (replace yourDatabase with your actual database connection):

const mongoose = require('mongoose');

const RoleSchema = new mongoose.Schema({
  name: {
    type: String,
    required: true,
    unique: true
  },
  permissions: {
    type: Array,
    required: true
  }
});

const PermissionSchema = new mongoose.Schema({
  name: {
    type: String,
    required: true,
    unique: true
  }
});

module.exports = {
  Role: mongoose.model('Role', RoleSchema),
  Permission: mongoose.model('Permission', PermissionSchema),
  connectToDatabase: async (uri) => await mongoose.connect(uri)
};

When a user attempts to perform an action, you can check their role and the associated permissions to determine if they are authorized to perform the requested action.

Here's an example middleware function in Express.js that checks if a user has the required permission:

const checkPermission = (requiredPermission) => {
  return (req, res, next) => {
    const userRole = req.user.role; 
    if (permissions[userRole].includes(requiredPermission)) {
      next(); 
    } else {
      res.status(403).json({ message: 'Forbidden' }); 
    }
  }
}

You can then use this middleware function to protect routes that require specific permissions:

app.get('/admin', checkPermission('edit'), (req, res) => {
  // Route logic for administrators
});

However, as the application grows, this approach can become unwieldy, leading to a large and difficult-to-maintain middleware. To address this, you can opt to use a dedicated authorization service like Permify, which provides a more robust and scalable solution.

Permify is an open-source, Golang-based authorization service that allows you to model your authorization logic using its domain-specific language (Permify Schema). This service can be set up independently of your application and provides a centralized API for making authorization decisions.

This approach promotes a clean separation of concerns, making your application more maintainable and scalable, especially in a microservices architecture where multiple services need to share and coordinate authorization decisions.

Using Permify to Model a Permission Model

Building a robust authorization service from scratch is a complex task. It requires handling various aspects such as storing authorization data models, managing authorization policies, and supporting a wide range of authorization models.

Instead of building a custom authorization service, you can take advantage of an existing solution.

Permify provides a powerful and flexible way to model and manage fine-grained authorizations across your applications and services.

The key benefits of using Permify include:

1. Decoupled Authorization Logic: You can define your entities, relations, and actions (permissions) in a separate service, keeping your application code focused on the core business logic. Permify handles the complexity of managing your authorization model.

2. Centralized Authorization API: Permify provides a centralized API for making authorization decisions, eliminating the need to re-implement authorization logic in each of your services. This makes development quicker and easier, and changes to authorization logic are made in a single place.

3. Flexible Authorization Modeling: Permify's domain-specific language (Permify Schema) allows you to model your authorization logic in a way that is not tied to your application's implementation. This makes it easier to maintain and evolve your authorization policies over time.

4. Cross-Service Authorization Coordination: In a microservices architecture, you often need to share authorization data across services. Permify's centralized approach makes it easier to coordinate authorization decisions between multiple services.

Now, let's see how you can use Permify service to model and implement an RBAC authorization model.

To get started with Permify, follow the steps in this documentation to quickly set up the service locally using Docker. Once you have Permify running, you can start modeling your authorization system.

Let's walk through an example of modeling a simple permissions system for a blog application. We'll use Permify's playground to quickly experiment and test this permission schema.

entity user {}

entity permify {
    // organizational roles
    relation admin @user
    relation member @user
}
entity blog {
    // represents blog parent organization
    relation parent @permify
    
    // represents owner of this blog
    
    relation owner  @user
    relation creator @user 

    // permissions/actions  
    permission edit   = parent.admin or owner or creator
    permission write = creator
    permission delete = owner
}

In this example, we have three main entities:

• user: Represents the users of the system.

• permify: Represents the organizational roles, such as "admin" and "member".

• blog: Represents the resource in the system, with associated permissions.

Entities, in this case, represent the core components or objects in your authorization system. They define your resources that have require access rights in your permission system.

The permissions are defined as follows:

• write permission is granted to the blog creator.
• edit permission is granted to the blog creator, admin or blog owner.
• delete permission is granted to the blog owner.

Ideally, in simple terms, what we have just done is defined the roles and the corresponding permission sets for certain resources. In a different guide we'll explore in detail entity relantionships, the importance, and potential use cases. However, if you are curious, you take a look at Permify documentation.

After modeling your authorization system using the Permify Schema, the next step is to configure the authorization model on the Permify service.

To do this, you'll need to send the Permify Schema to the Permify service using the Write Schema API. This ensures that your authorization schema is stored by the service, which Permify will then use to enforce the authorization system.

There are two ways to interact with the authorization service's Writer API endpoint:

1. Programmatically: You can integrate the API calls directly into your Node.js or Go application by following the instructions in the Writer API reference documentation.

2. Manually: For demonstration purposes, we'll use an API client like Postman to send requests to this endpoint.

http://localhost:3476/v1/tenants/t1/schemas/write

In the request body, include the Permify Schema as a JSON object:

{
  "schema": "your_schema_definition"
}

Replace "your_schema_definition" with the Permify Schema you defined earlier in the playground.

After writing the schema, you need to add relation tuples to the Permify service. Relation tuples in Permify represent the underlying data form that captures relationships between entities, objects, and users, essentially constituting access control lists (ACLs).

Each relation tuple signifies an action that a specific user or set of users can perform on a resource. These relational tuples are fundamental to defining and enforcing access control within the Permify model.

To add some sample relation tuples based on your permission model, make an API call to this endpoint:

http://localhost:3476/v1/tenants/t1/data/write

In the request body, include the relation tuples as a JSON object and include the schema version you obtained from the previous request:

{
  "metadata": {
    "schema_version": "your-schema-version"
  },
  "tuples": [
    {
      "entity": {
        "type": "blog",
        "id": "1"
      },
      "relation": "creator",
      "subject": {
        "type": "user",
        "id": "1",
        "relation": ""
      }
    }
  ]
}

This example assigns a particular user with an ID "1" a "creator" role for the "blog" entity with ID "1". The key point is that these relation tuples define the underlying access control logic, which Permify will then use to enforce your authorization model.

If your request is successful, you'll receive a "snap token" . This token contains an encoded timestamp. This timestamp guarantees that access control checks are based on a snapshot of data that's at least as up-to-date as the resource itself. This ensures consistent access decisions even if resource data changes slightly between requests.

After completing the steps of writing the schema and adding relation tuples, you can start performing authorization checks using the Permify Check API.

To check whether a specific user (the creator) has access to edit a blog, you can make an API call to the following endpoint:

http://localhost:3476/v1/tenants/t1/check

In the request body, include the following information:

{
  "metadata": {
    "schema_version": "<your_schema_version>",
    "snap_token": "<your_snap_token>",
    "depth": 20
  },
  "entity": {
    "type": "permify",
    "id": "1"
  },
  "permission": "edit",
  "subject": {
    "type": "user",
    "id": "1",
    "relation": ""
  }
}

Using the valid schema_version and snap_token values from the previous requests, along with the user ID "1", will result in a RESULT_ALLOW response, as we have granted the user with an ID of "1" the "creator" role for the "blog" entity.

Essentially, what we have just demonstrated is how Permify's authorization service works separately from your application. If your application already has an authentication solution in place, and you want to add fine-grained authorization capabilities on top of it, you can quickly set up the Permify authorization service.

Permify allows you to seamlessly integrate authorization functionality into your existing application infrastructure by making API calls to the Permify service from any of your system's services.

This integration can be achieved regardless of the technology stack or programming languages used in your application, as Permify operates as a separate, dedicated authorization service.

Summary

Role-based access control (RBAC) is a widely adopted access control model that regulates permissions and access based on the roles assigned to users within an organization.

In this guide, we have explored in detail what RBAC is and the underlying fundamental concepts, including different models. We have also examined how to implement RBAC models using the Permify authorization service.

If you want to further explore and learn more about this topic, please refer to Permify's official documentation.