Authorization Pattern

Authorization pattern là cách thiết kế logic kiểm soát quyền truy cập trong một hệ thống, nói nôm na là:

ACL = Ai (Who) có quyền gì (What) trên tài nguyên nào (Resource)

Authorization pattern không chỉ là một hàm check quyền, mà là một tư duy thiết kế— bao gồm cách tổ chức dữ liệu, quan hệ giữa user, role, resource, và policy.
Có 3 loại Authorization pattern thông dụng:
- Access Control List
- RBAC (Role-Based Access Control)
- ABAC (Attribute-Based Access Control)

Access Control List

Tổng quan

Access Control List (ACL) là một trong những mô hình authorization pattern cổ điển và phổ biến nhất trong các hệ thống phần mềm.
ACL được sử dụng để xác định quyền truy cập (permission) của từng đối tượng (user, group) lên tài nguyên cụ thể (resource) trong hệ thống.
Nói một cách dễ hiểu:

ACL là “danh sách quyền truy cập” được gắn trực tiếp vào từng tài nguyên, giúp hệ thống biết được ai có thể làm gì với cái gì.

👉 Ưu điểm: cực kỳ linh hoạt, kiểm soát đến từng resource
👉 Nhược điểm: phức tạp khi quản lý quy mô lớn

Khái niệm chính

Thuật ngữ	Mô tả
Principal	Thực thể được cấp quyền – có thể là User hoặc Group.
Resource	Đối tượng được bảo vệ – file, record, API endpoint, document, v.v.
Permission	Hành động được phép thực hiện – ví dụ: READ, WRITE, DELETE.
ACL Entry (ACE)	Một bản ghi trong danh sách ACL thể hiện “ai được phép làm gì trên tài nguyên nào”.

Sơ đồ

Câu hỏi thường gặp

Có nên có permission_full_role (hay kiểu như ADMIN, FULL_ACCESS) trong bảng permissions không?

Trả lời:

Khi bạn nói đến permission_full_role (ví dụ như "FULL_ACCESS", "ADMIN_PRIVILEGE"), thực chất bạn đang nói đến tập hợp quyền tổng hợp, chứ không phải “một quyền cụ thể”.
Ví dụ:
- FULL_ACCESS = { READ, WRITE, DELETE, SHARE, EXECUTE }
Nó là role disguised as a permission — nghĩa là bạn đang đưa khái niệm Role vào tầng Permission, và điều đó làm rối ACL model.
ACL được thiết kế để:
- permission = hành động đơn lẻ (atomic)
- resource = đối tượng cụ thể (specific)
- user/group = principal
Nếu bạn thêm FULL_ACCESS, bạn phá vỡ tính atomicity (quyền nhỏ nhất có thể).

Role-Based Access Control (RBAC)

Cấu trúc ACL rất chi tiết, linh hoạt, nhưng khi hệ thống có nhiều người dùng và nhiều resource, nó bắt đầu bộc lộ hạn chế:

Vấn đề	Mô tả
🔁 Trùng lặp cấu hình	Nhiều user có cùng quyền, phải thêm nhiều ACL entry giống nhau.
🔄 Khó bảo trì	Khi cần thay đổi policy (ví dụ thêm quyền “EDIT”), phải cập nhật hàng loạt bản ghi.
🧩 Khó gắn với vai trò tổ chức	ACL chỉ hiểu user, group, resource — không phản ánh được “vị trí” hay “vai trò” trong hệ thống (admin, editor, viewer, …).

Tổng quan

Role-Based Access Control (RBAC) là mô hình phân quyền dựa trên vai trò (role) — một khái niệm trừu tượng đại diện cho vị trí hoặc chức năng của người dùng trong hệ thống.
Khác với ACL (Access Control List) — nơi quyền được gán trực tiếp cho từng user hoặc group, RBAC gom nhóm các quyền (permissions) lại và gán cho role, rồi user được gán role, từ đó gián tiếp nhận toàn bộ quyền tương ứng, chỉ ra

RBAC = Ai (Who) thuộc vai trò nào (Role), và vai trò đó có quyền gì (What) trên tài nguyên nào (Resource)

Ví dụ:
- Thay vì: "User A có quyền WRITE Article"
- Ta định nghĩa: "Role Editor có quyền WRITE Article"
- Và "User A có role Editor"
  → Kết quả: User A tự động có quyền WRITE Article.
RBAC ra đời nhằm giải quyết vấn đề quản trị và mở rộng quyền hạn trong hệ thống có nhiều người dùng hoặc nhiều loại tài nguyên.
Khi số lượng user và resource tăng, việc duy trì danh sách ACL riêng cho từng user trở nên rất tốn công và dễ sai lệch.
RBAC giúp:
- Tái sử dụng quyền thông qua role chung.
- Giảm trùng lặp cấu hình giữa nhiều user có cùng quyền.
- Dễ thay đổi chính sách phân quyền (chỉ cần cập nhật role, không cần chỉnh từng user).
- Phản ánh đúng cơ cấu tổ chức nghiệp vụ (Admin, Editor, Viewer, Staff…).

Khái niệm chính

Thành phần	Mô tả
User	Người dùng thực tế trong hệ thống. Một user có thể giữ nhiều role.
Role	Đại diện cho một vai trò hoặc chức năng (Admin, Editor, Viewer…).
Permission	Mô tả hành động có thể thực hiện (READ, WRITE, DELETE…).
Resource	Đối tượng mà permission áp dụng lên (Document, Article, Project…).

💡 Trong RBAC, user không trực tiếp gắn với permission, mà thông qua role.

Sơ đồ

Câu hỏi thường gặp

1.Có nên xem Role của RBAC là Group của ACL ?

Khác biệt nằm ở ý nghĩa và khả năng mở rộng

Tiêu chí	ACL (xem group như role)	RBAC (role là thực thể riêng)
🧠 Ngữ nghĩa (Semantics)	“Group” chỉ là tập người dùng – không định nghĩa hành vi hay chức năng.	“Role” định nghĩa rõ chức năng trong hệ thống (“Editor có quyền chỉnh sửa bài viết”).
⚙️ Permission scope	Permission gắn trực tiếp vào group/resource.	Permission gắn vào role, role có thể dùng lại ở nhiều nơi.
🧩 Tính kế thừa (Hierarchy)	Group không dễ định nghĩa “Admin kế thừa quyền của Editor”.	RBAC hỗ trợ role hierarchy (Admin ⊃ Editor ⊃ Viewer).
🔁 Tái sử dụng	Mỗi group mapping với resource cụ thể → dễ trùng lặp.	Role độc lập với resource, chỉ cần gán 1 lần, tái sử dụng toàn hệ thống.
🧱 Tổ chức và bảo trì	Khi policy thay đổi (thêm quyền mới), phải cập nhật nhiều ACL entries.	Chỉ cần sửa 1 role → tất cả user thuộc role đó được cập nhật theo.

Về kỹ thuật:
Bạn hoàn toàn có thể implement role như group trong ACL — vẫn hoạt động tốt, nhất là cho hệ thống nhỏ hoặc single-domain.
⚠️ Về kiến trúc dài hạn:
Khi hệ thống phức tạp hơn, với nhiều loại resource, nhiều module, nhiều vai trò kế thừa hoặc domain khác nhau,
→ lúc đó RBAC tách role ra thành thực thể riêng là bắt buộc để quản lý nhất quán và mở rộng.

💡 Một cách nhìn ngắn gọn:
“Group” trong ACL = tập người dùng (về mặt tổ chức).
“Role” trong RBAC = tập hành vi (về mặt chức năng).

Attribute-Based Access Control (ABAC)

Tổng quan

ABAC (Attribute-Based Access Control) diễn giải quyền truy cập không chỉ dựa vào “ai” hay “thuộc role nào” (như RBAC), mà dựa vào “thuộc tính (attribute)” của mọi thực thể liên quan trong quá trình truy cập:

Thành phần	Ý nghĩa
Subject attributes	Thuộc tính của người thực hiện hành động (ví dụ: `user.department`, `user.age`, `user.role`)
Resource attributes	Thuộc tính của tài nguyên (ví dụ: `document.owner_department`, `project.confidentiality_level`)
Action attributes	Hành động đang yêu cầu (ví dụ: `read`, `write`, `delete`)
Environment attributes	Bối cảnh của yêu cầu (ví dụ: `request.time`, `request.location`, `device.type`)

Thay vì gán quyền cứng như ACL (“User A có quyền READ File X”) hay RBAC (“Role Editor có quyền WRITE Article”),
ABAC cho phép ta xác định quyền thông qua policy có điều kiện, ví dụ:

Cho phép truy cập nếu user.department == resource.department
và environment.time < 18:00.

Khái niệm chính

Tên bảng	Mô tả
users	Lưu thông tin người dùng cùng các thuộc tính (subject attributes) như `role`, `department`, `country`, `clearance_level`, … để PDP sử dụng khi đánh giá policy.
resources	Lưu thông tin tài nguyên có thể bị truy cập (resource attributes), ví dụ: `type`, `owner_id`, `sensitivity_level`, `status`, …
actions	Lưu danh sách các hành động được phép trong hệ thống như `read`, `write`, `delete`, `approve`, …
policies	Đại diện cho một chính sách (policy) cụ thể, chứa tên, mô tả, hiệu ứng (`allow` hoặc `deny`), và mức độ ưu tiên. Mỗi policy gồm nhiều rule.
policy_rules	Lưu các điều kiện chi tiết của từng policy. Mỗi dòng biểu diễn một rule dựa trên thuộc tính (subject/resource/action/context), ví dụ: `subject.role = 'admin'`, `resource.type = 'article'`, `action = 'delete'`.
context_data (optional)	Lưu các thuộc tính ngữ cảnh (context attributes) như thời gian, địa điểm, IP hoặc thiết bị đang truy cập. Dùng khi policy có điều kiện phụ thuộc vào ngữ cảnh.
policy_effects (optional)	Xác định hành động của policy khi match (`allow`, `deny`, `audit`). Có thể dùng nếu hệ thống hỗ trợ nhiều loại hành động ngoài cho phép / từ chối.
policy_logs (optional)	Ghi lại kết quả đánh giá policy của PDP — ai truy cập, policy nào được áp dụng, kết quả cho phép hay từ chối, dùng cho mục đích audit.

Ví dụ về Policy

Policy ID	Rule
1	`allow if user.role == 'manager' and resource.department == user.department`
2	`allow if user.clearance >= resource.classification`
3	`deny if environment.location != 'office'`