RBAC And Permissions

Learn RBAC And Permissions for free with explanations, exercises, and a quick test (for Backend Engineer).

Published: January 20, 2026 | Updated: January 20, 2026

Why this matters

Example 3: Combining RBAC with attribute checks

Hint

Order: superuser → suspension → project roles → workspace roles → deny.

I used deny-by-default.
I covered background jobs or non-HTTP flows.
I included audit logging for sensitive allows/denies.

Practical projects

Add RBAC middleware to a demo REST API (users, projects, tasks). Include unit tests for common and edge cases.
Implement project-scoped roles and a role editor seed script.
Add an audit log service that records who did what, where, and why (decision summary).
Create a migration to introduce a new permission without breaking existing roles.

Who this is for

Backend Engineers building multi-user systems.
Developers adding authorization to existing APIs.
Engineers preparing for security-conscious teams and audits.

Prerequisites

Comfort with API design and HTTP status codes.
Basic database modeling.
Familiarity with authentication (tokens/sessions), as authz builds on top.

Learning path

Understand RBAC basics and least privilege.
Model permissions, roles, and resource scopes.
Implement a checker with deny-by-default + audits.
Add caching and cover background processes.
Test, monitor, and iterate with real usage.

Next steps

Automate permission tests with fixtures covering resource scopes.
Introduce just-in-time elevation flows for rare admin tasks.
Review logs for noisy denies and refine roles safely.

Mini challenge

Your product manager wants "export_all_data" for managers. Propose a safer alternative using existing permissions. Explain why it’s safer and how to instrument audits. Write your answer in 5–7 bullet points.

Reminder: The quick test is open to all learners. Log in if you want your progress saved.

Practice Exercises

2 exercises to complete

Instructions

Design RBAC for a project tool with resources: Workspace, Project, Task, Comment. Roles: Owner, Manager, Member, Guest. Requirements:

Guest can only read project and task titles.
Member can create tasks and comments; can update/delete only own tasks/comments.
Manager can manage tasks for the project, invite members to the project, but cannot delete the workspace.
Owner can do everything, including workspace admin actions.
Project-scoped roles should override workspace roles for that project.

Output a concise role → permissions mapping. Indicate which permissions are project-scoped.

Expected Output

A role-permission mapping that shows least privilege, resource scoping, and ownership checks. Example: Member: {task:{create, read, update_own, delete_own}, comment:{create, read, delete_own}}; Guest: {project:{read}, task:{read_title}}; Manager: {project:{invite, read}, task:{create, read, update, delete}, comment:{create, read, delete}}; Owner: {workspace:{manage_org, delete_org}, project:{all}, task:{all}, comment:{all}}.