 |
This slide shows how access control has evolved as systems became more complex.
We started with RBAC — Role-Based Access Control.
Here, access is based on who you are in the organization. If you¡¯re assigned the role ¡®Editor¡¯, you can view and edit documents. It¡¯s simple and works well in structured environments, but it becomes rigid. Everyone with the same role gets the same permissions, even when context differs.
Next came ABAC — Attribute-Based Access Control.
Instead of just roles, decisions use attributes — things like location, department, or device. For example, a user can edit a document only if their location is the USA. This adds flexibility, but policies become harder to reason about because you¡¯re evaluating many conditions at runtime.
Modern large-scale systems moved to ReBAC — Relationship-Based Access Control.
Here, permissions come from relationships in a graph. Instead of saying ¡®you are an editor¡¯, we say ¡®you are an editor of Folder A¡¯. Because Folder A contains documents, you automatically get access to all documents inside. This matches how real systems work — users, teams, resources, and hierarchies are all connected.
So the shift is from roles ¡æ attributes ¡æ relationships, with ReBAC being the model that powers systems like Google Zanzibar because it scales naturally with complex, interconnected data. |
IEEE/ICACT20260076 Slide.03
[Big Slide]
[YouTube]