CodeWithAbdessamad

Authorization

Authorization

Role-Based Access Control (RBAC)

Imagine you’re managing a team of developers. You don’t want to give every developer full access to the codebase. Instead, you create roles: Developer, Manager, and QA. Each role has specific permissions. This is the essence of Role-Based Access Control (RBAC).

RBAC is a security model where permissions are assigned to roles, and users are assigned to roles. This creates a hierarchical structure that simplifies permission management. For example:

  1. User alice is assigned the Developer role.
  2. Role Developer has permissions: readcode, writecode.
  3. User bob is assigned the QA role.
  4. Role QA has permissions: readcode, executetests.

This model ensures users only have necessary permissions, reducing accidental or malicious data exposure.

Here’s a concrete Python implementation:

<code class="language-python">class RBAC:
<p>    def <strong>init</strong>(self):</p>
<p>        self.users = {}</p>
<p>        self.roles = {}</p>
<p>        self.role_permissions = {}  # role -> list of permissions</p>

<p>    def add<em>user</em>to_role(self, user, role):</p>
<p>        if user not in self.users:</p>
<p>            self.users[user] = []</p>
<p>        self.users[user].append(role)</p>

<p>    def add<em>role</em>permissions(self, role, permissions):</p>
<p>        self.role_permissions[role] = permissions</p>

<p>    def check_permission(self, user, permission):</p>
<p>        for role in self.users.get(user, []):</p>
<p>            if permission in self.role_permissions.get(role, []):</p>
<p>                return True</p>
<p>        return False</p>

<h1>Initialize RBAC system</h1>
<p>rbac = RBAC()</p>

<h1>Add roles and permissions</h1>
<p>rbac.add<em>role</em>permissions("Developer", ["read<em>code", "write</em>code"])</p>
<p>rbac.add<em>role</em>permissions("QA", ["read<em>code", "execute</em>tests"])</p>

<h1>Assign users to roles</h1>
<p>rbac.add<em>user</em>to_role("alice", "Developer")</p>
<p>rbac.add<em>user</em>to_role("bob", "QA")</p>

<h1>Check permissions</h1>
<p>print(rbac.check<em>permission("alice", "read</em>code"))  # Output: True</p>
<p>print(rbac.check<em>permission("bob", "execute</em>tests"))  # Output: True</code>

The RBAC class demonstrates role-based permission management. The check_permission method verifies user permissions by checking assigned roles and their permissions.

Access Control Lists (ACLs)

Now, let’s shift focus to Access Control Lists (ACLs). Unlike RBAC, which groups permissions by roles, ACLs are explicit lists of permissions attached to a specific resource. Think of them as a “bill of rights” for a resource: who can do what on it.

ACLs are commonly used in file systems (like Linux) and network devices (like firewalls). For example, in a Linux file system, an ACL for a file might look like this:

<code>user: alice -> read, write
<p>user: bob -> read</p>
<p>group: developers -> read</code>

This means:

  • User alice has read and write permissions.
  • User bob has read permissions.
  • All users in the developers group have read permissions.

ACLs offer fine-grained control, enabling specific permissions for users/groups without creating new roles.

Here’s a runnable Python example:

<code class="language-python"># Simulate an ACL for a file
<p>file_acl = {</p>
<p>    "report.txt": [</p>
<p>        {"user": "alice", "permissions": ["read", "write"]},</p>
<p>        {"user": "bob", "permissions": ["read"]},</p>
<p>        {"group": "developers", "permissions": ["read"]}</p>
<p>    ]</p>
<p>}</p>

<h1>Check if a user has permission for a file</h1>
<p>def has<em>permission(file</em>name, user, permission):</p>
<p>    acl = file<em>acl.get(file</em>name)</p>
<p>    if not acl:</p>
<p>        return False</p>
<p>    for entry in acl:</p>
<p>        if entry.get("user") == user and permission in entry["permissions"]:</p>
<p>            return True</p>
<p>    return False</p>

<h1>Example usage</h1>
<p>print(has_permission("report.txt", "alice", "read"))  # Output: True</p>
<p>print(has_permission("report:report.txt", "bob", "write"))  # Output: False</code>

This example shows ACLs working at the resource level. Each file has its own ACL, and permissions are checked per entry.

Key difference: In RBAC, permissions are managed at the role level and applied to users. In ACLs, permissions are explicitly listed for each resource.

Feature Role-Based Access Control (RBAC) Access Control Lists (ACLs)
Permission Management Roles define permissions; users assigned to roles Explicit permissions listed per resource for users/groups
Scalability High (roles can be grouped and permissions inherited) Moderate (complexity increases with many resources)
Use Case Enterprise applications, teams with defined roles File systems, network devices requiring fine-grained control
Example Developer role: readcode, writecode File report.txt: alice has read, write; bob has read

Summary

In this section, we explored two foundational authorization models: Role-Based Access Control (RBAC) and Access Control Lists (ACLs).

RBAC provides a hierarchical structure for managing permissions through roles, making it ideal for enterprise environments. ACLs offer granular control by explicitly listing permissions for specific resources, crucial for file systems and network devices. Both models are essential tools in cybersecurity, and understanding their differences helps choose the right approach for your security needs.

By mastering these concepts, you’ll be better equipped to design robust access control systems that balance security and usability. 🔒