We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A growing SaaS company started by giving each employee individual permissions. Alice can read invoices and edit customers. Bob can do everything Alice can plus delete users. With 20 employees, this was manageable. At 500 employees, it collapsed. Every new hire needed a custom permission set. Team transfers required manually updating dozens of entries. When an auditor asked "who can delete customer data?", the answer took three weeks to compile because there was no structure to query against.
RBAC replaces per-user permissions with an intermediary: roles. You define roles (Admin, Editor, Viewer). You attach permissions to roles. You assign roles to users. When someone joins the marketing team, they get the "Marketing Editor" role and instantly inherit every permission it carries. When they transfer to engineering, swap the role. When the auditor asks about delete access, you check which roles carry that permission and list the users with those roles. One query, thirty seconds.
AWS IAM, , Google Workspace, Stripe Dashboard, and virtually every SaaS admin panel use RBAC. It is the default for a reason: it handles 90% of authorization requirements with minimal complexity.
Three core concepts:
| Concept | What It Means | Example |
|---|---|---|
| User | A person or service account | alice@company.com |
| Role | A named collection of permissions | "Editor", "Admin", "Viewer" |
| Permission | A specific action on a resource type | "invoices:read", "users:delete" |
Users are assigned to roles. Roles hold permissions. Users never receive permissions directly.
Role hierarchy reduces duplication. An Admin role inherits everything from Editor, which inherits from Viewer. This means the Admin definition only contains the permissions unique to admins (user management, billing), not the ones already covered by lower roles.
Common production roles:
| Role | Typical Permissions | Real-World Example |
|---|---|---|
| Viewer | Read-only | Auditor viewing dashboards |
| Editor | Read + Create + Update | Content writer in a CMS |
| Admin | Full CRUD + user management | Team lead managing access |
| Super Admin | Everything + billing + security | CTO or platform owner |
| Support | Read + impersonate users | Customer success agent |
Role explosion is the anti-pattern to watch for. If you end up with 200 roles, each representing a specific combination of permissions, you have lost the abstraction benefit. Keep roles aligned with actual job functions, not arbitrary permission bundles.
When NOT to use RBAC alone: when access depends on attributes beyond the user's role. "Managers can view reports only for their own department" requires evaluating the relationship between the user and the resource at request time. Pure RBAC cannot express that. You need ABAC or a hybrid.