Access Control Models: ACL, RBAC, ABAC
In system design, access control is a critical mechanism to ensure data security and correct authorization of functionalities. Depending on the complexity of the system, the variety of user roles, and the flexibility needed in resource management, there are three common access control models: ACL (Access Control List), RBAC (Role-Based Access Control), and ABAC (Attribute-Based Access Control). Below is a brief comparison of these three models, outlining their design logic, characteristics, and application scenarios to help clarify the selection and implementation considerations.
ACL
Direct authorization, fine-grained, but difficult to manage
- Design Logic: User → Resource + Operation
If a user has read and update permissions for the development department's file list, they can view all the data under that department and make changes to it.
RBAC
Simplified management, clear structure, but limited flexibility
- Design Logic: Role → Resource + Operation; User is assigned to a role
If a user’s role is a department manager, they can perform CRUD operations on all resources within that department.
ABAC
Highest flexibility, dynamic condition evaluation based on the user's, resource's, and environment's attributes to determine authorization.
Some variants include ReBAC (Relationship-Based Access Control), LBAC (Label-Based Access Control).
- Design Logic: Access is determined based on attributes.
If a user’s department attribute is "HR Department," the resource's attribute is "personnel data," and the current time is within working hours, access is granted.
Comparison Table
| Item | ACL (Access Control List) | RBAC (Role-Based Access Control) | ABAC (Attribute-Based Access Control) |
|---|---|---|---|
| 📘 Authorization Target | User → Resource | Role → Resource | User attributes, resource attributes, environment attributes |
| 👤 User Binding Method | User is directly granted access | User is assigned a role | User attributes are used to check access |
| 🔄 Authorization Method | Static (each rule is defined clearly) | Static (role-based) | Dynamic condition-based (using multiple attributes) |
| 🧱 Database Design Simplicity | Simple (but hard to scale) | Moderate | Complex (requires extra logic for attributes and rules) |
| ⚙️ Flexibility / Detail Control | High (per user and resource) | Medium (role-level) | Very high (can use any attribute condition) |
| 📈 Maintenance Cost (Large Systems) | High (hard to manage when users grow) | Low to medium (if roles are well designed) | High (complex rules and attributes need engine support) |
| 🔐 Permission Sharing / Inheritance | Low (granted per user) | High (shared roles, hierarchical roles) | High (attributes are reusable) |
| 🛡️ Suitable Resource Scale | Small (few users and resources) | Medium to large (with stable role structure) | Large and complex (many rules, multi-tenant) |
| 🧠 Learning / Implementation Difficulty | Low | Low to medium | High (requires abstract thinking, policy language like XACML or engines like OPA) |
| 🧭 Suitable Use Cases | Personal systems, sensitive data with fine control | Enterprise backends, SaaS, shared platforms | Banks, government, insurance, dynamic access control, zero-trust |
| 🧩 Typical Examples | Dropbox, Google Drive “share with someone” | Internal company systems (e.g., Admin, Manager) | Data classification access, policy-driven API Gateway |
| 👮🏻♂️ Security | High (fine control, but human error risk) | Medium (depends on good role design) | High (granular control, but needs accurate rules/attributes) |
| 🏎️ Performance | Decreases with scale (each access is checked) | High (simple role lookup) | Low (many attributes and rules to evaluate) |
| 🎲 Standard Support | None | NIST RBAC Model | XACML |
