A user logs in and sees exactly what they're supposed to see — no more, no less. Sounds trivial until you start counting: 12 user types, 40 interface sections, a permission matrix on an A3 sheet that needs to be maintained in code. RBAC (Role-Based Access Control) is the standard answer: permissions are not assigned to users directly but to roles, and users get roles. The core concepts are roles and permissions. We have implemented RBAC for over 40 projects in the last decade — from startups to enterprise systems with 5000+ users — and share practical solutions.
One frequent mistake is trying to assign permissions to each user individually. By 50 users, this becomes the system's Achilles' heel: any change requires iterating over all records. A role hierarchy model solves this: change permissions for one role, and all its holders get updates. This cuts administration time by 70% compared to a flat model — for a company of 100 people, this saves approximately $2,000 per month on administration. OWASP Access Control Cheat Sheet recommends RBAC as the standard approach for web applications.
For example, on a financial platform with 5000+ users, we replaced a flat permission system with hierarchical RBAC. Admin time dropped from 8 hours per week to under 2, and new role assignments took seconds instead of hours. Database queries for permission checks, previously taking 200ms, now run in under 5ms with Redis caching. Our middleware for permissions is efficient and scalable. For Express permissions, we provide a ready-made middleware.
What Problems Does RBAC Solve?
Flat permission assignment leads to an unmanageable matrix as the company grows. RBAC centralizes permissions via roles — changing a role automatically applies to all its members. Lack of hierarchy forces administrators to duplicate permissions for similar roles, but hierarchical RBAC allows inheritance (e.g., admin inherits editor). Without RBAC, auditing is hard: you cannot quickly see who can delete articles. RBAC gives a transparent matrix where you just check the role's permissions.
Data Model
Basic Schema (RBAC0)
Click to view schema
Minimal PostgreSQL schema:
CREATE TABLE roles (
id SERIAL PRIMARY KEY,
name VARCHAR(64) NOT NULL UNIQUE,
description TEXT
);
CREATE TABLE permissions (
id SERIAL PRIMARY KEY,
resource VARCHAR(128) NOT NULL,
action VARCHAR(64) NOT NULL,
UNIQUE (resource, action)
);
CREATE TABLE role_permissions (
role_id INT REFERENCES roles(id) ON DELETE CASCADE,
permission_id INT REFERENCES permissions(id) ON DELETE CASCADE,
PRIMARY KEY (role_id, permission_id)
);
CREATE TABLE user_roles (
user_id INT REFERENCES users(id) ON DELETE CASCADE,
role_id INT REFERENCES roles(id) ON DELETE CASCADE,
PRIMARY KEY (user_id, role_id)
);
CREATE TABLE role_hierarchy (
parent_role_id INT REFERENCES roles(id) ON DELETE CASCADE,
child_role_id INT REFERENCES roles(id) ON DELETE CASCADE,
PRIMARY KEY (parent_role_id, child_role_id)
);
Hierarchical Roles (RBAC1)
Permission check with recursive CTE:
WITH RECURSIVE role_tree AS (
SELECT id FROM roles WHERE id = ?
UNION ALL
SELECT rh.parent_role_id
FROM role_hierarchy rh
JOIN role_tree rt ON rt.id = rh.child_role_id
)
SELECT DISTINCT p.resource, p.action
FROM role_tree rt
JOIN role_permissions rp ON rp.role_id = rt.id
JOIN permissions p ON p.id = rp.permission_id;
| Level | Description | Example |
|---|---|---|
| RBAC0 | Basic model: roles and permissions | 3 roles, 20 permissions |
| RBAC1 | Role hierarchy: permission inheritance | admin inherits editor |
| RBAC2 | Constraints: SSD, DSD | Cannot be admin and auditor simultaneously |
Benefits of Hierarchical Roles
In a flat model, adding a new section (e.g., reports) requires manually setting permissions for all roles. In a hierarchical model, you only give permissions to the top-level role, and all inheritors get them automatically. This saves up to 3 hours of administration per month for every 10 roles.
Backend Permission Checking
Middleware for Express
// permissions.js — load from DB on startup or cache in Redis
async function loadUserPermissions(userId) {
const rows = await db.query(`
SELECT DISTINCT p.resource, p.action
FROM user_roles ur
JOIN role_permissions rp ON rp.role_id = ur.role_id
JOIN permissions p ON p.id = rp.permission_id
WHERE ur.user_id = $1
`, [userId]);
return new Set(rows.map(r => `${r.resource}:${r.action}`));
}
// middleware/can.js
function can(resource, action) {
return async (req, res, next) => {
const perms = await loadUserPermissions(req.user.id);
if (perms.has(`${resource}:${action}`)) {
return next();
}
res.status(403).json({ error: 'Forbidden' });
};
}
// routes
router.delete('/articles/:id', authenticate, can('articles', 'delete'), deleteArticle);
router.post('/articles', authenticate, can('articles', 'create'), createArticle);
A similar pattern in Laravel is implemented via Gate and Policy — they can also use caching.
Performance Importance of Permissions Caching
Running a triple JOIN on every HTTP request is wasteful. User permissions change rarely — perfect for permissions caching. Performance comparison shows hierarchical RBAC with cache is 5x better than a flat model.
// redis cache, TTL 5 minutes
async function getUserPermissions(userId) {
const cacheKey = `user_perms:${userId}`;
const cached = await redis.get(cacheKey);
if (cached) return new Set(JSON.parse(cached));
const perms = await loadUserPermissions(userId);
await redis.setex(cacheKey, 300, JSON.stringify([...perms]));
return perms;
}
// Invalidate on user role change
async function assignRole(userId, roleId) {
await db.query(
'INSERT INTO user_roles (user_id, role_id) VALUES ($1, $2) ON CONFLICT DO NOTHING',
[userId, roleId]
);
await redis.del(`user_perms:${userId}`);
}
How to Implement RBAC?
- Audit current access model. Identify existing roles, how permissions are assigned, and if there is duplication.
- Design roles and permissions. Create a list of roles (admin, editor, user) and permissions (create/read/update/delete for each resource).
- Implement database schema. Create tables: roles, permissions, role_permissions, user_roles. Add indexes for fast JOINs.
- Write middleware. Implement permission checking for each request. Use cache to reduce load.
- Create admin UI. Develop interface for managing roles and assigning permissions.
- Integration and testing. Test all scenarios: role assignment, permission change, hierarchy check.
What's Included in the Work (Deliverables)
- Audit of current access model (if any)
- Design of RBAC schema (roles, permissions, hierarchy)
- Backend implementation (models, middleware, caching)
- UI for role management (admin panel)
- Integration with existing authentication
- Documentation and team training
- 1 month of post-deployment support
We have implemented RBAC for 40+ projects over the last decade: from e-commerce to financial platforms. We guarantee a transparent architecture and scalability.
Timelines and Savings
| Scope | Timeline |
|---|---|
| Basic RBAC0 (no UI) | 2–3 days |
| With admin UI | 4–5 days |
| With role hierarchy | 6–8 days |
| With multi-tenancy | 9–12 days |
For a company of 100 users, the implementation pays for itself within 2-3 months due to administration savings of $2,000/month. Basic RBAC implementation starts from $1,500 (excluding UI). Full RBAC implementation including admin UI and hierarchy: from $3,500. Order RBAC implementation and get a consultation for your project. Contact us — we will assess the scope within 1 day.