Xác thực (Authentication) và phân quyền (Authorization) trong kiến trúc microservices

 (microservices.io)
15 điểm bởi baeba 2025-05-13 | Chưa có bình luận nào. | Chia sẻ qua WhatsApp

Loạt bài này nói về cách triển khai xác thực (Authentication) và phân quyền (Authorization) trong kiến trúc microservices.
Bài viết này giải thích phần tổng quan và sự khác biệt so với ứng dụng đơn khối (monolithic).

Ứng dụng ví dụ: RealGuard.io

RealGuard.io là một nền tảng hệ thống an ninh thương mại, quản lý việc điều khiển thiết bị bảo mật và cảnh báo.
Người dùng thuộc về nhà bán hàng, công ty khách hàng và nhà cung cấp dịch vụ giám sát, mỗi bên có quyền truy cập khác nhau.

Xác thực và phân quyền trong kiến trúc đơn khối

Cấu trúc đơn khối gồm một ứng dụng và một cơ sở dữ liệu, trong đó xác thực được triển khai bằng session token.
Phân quyền được thực hiện theo cấu trúc như sau:

isAllowed(user, operation, resource)

Ví dụ:

isAllowed(user, "disarm", SecuritySystem(ID))

4 mô hình phân quyền

  1. RBAC: Kiểm soát truy cập dựa trên vai trò – xác định quyền theo vai trò được gán cho người dùng
  2. ReBAC: Kiểm soát truy cập dựa trên quan hệ – xác định truy cập theo quan hệ giữa người dùng và tài nguyên
  3. ABAC: Kiểm soát truy cập dựa trên thuộc tính – xác định theo thuộc tính của người dùng, tài nguyên và môi trường
  4. Mô hình kết hợp: Có thể kết hợp 3 mô hình trên để triển khai chính sách phức hợp

Ví dụ phân quyền và quyền hạn theo vai trò

Operation Required Role
getAlarmSystem() SecuritySystemViewer
armSystem() SecuritySystemArmer
disarmSystem() SecuritySystemDisarmer
cancelSystem() SecuritySystemAlarmCanceller

Ngoài vai trò cụ thể, còn có thể áp dụng thêm các điều kiện như ràng buộc giờ làm việc (ABAC) hoặc việc có nằm trong danh sách thông báo hay không.

Vị trí kiểm tra phân quyền

  1. Hạ tầng mạng: Có thể kiểm tra quyền đơn giản tại service mesh, ingress controller, v.v.
  2. REST API handler: Xử lý phân quyền coarse-grained ở mức request
  3. Logic domain: Xử lý phân quyền dựa trên điều kiện phức tạp
  4. Tầng truy cập DB: Lọc phân quyền bên trong SQL (hiệu quả cho xử lý khối lượng lớn)

Phân quyền trong UI

UI không thể tự ép buộc phân quyền, nhưng có thể tối ưu UX bằng cách hiển thị hoặc vô hiệu hóa nút/chức năng theo quyền của người dùng.

Xác thực trong kiến trúc microservices

BFF (Backend For Frontend) phụ trách đăng nhập và quản lý session.
Vì mỗi microservice chạy độc lập nên không thể truy cập trực tiếp thông tin người dùng từ session, mà phải truyền thông tin người dùng bằng token như JWT.

Phân quyền trong kiến trúc microservices

Request được truyền theo thứ tự BFF → SecurityService, và có thể kiểm tra phân quyền ở ba vị trí sau:

  1. BFF: Có thể phân quyền ở mức request theo đường dẫn và method dựa trên thông tin session
  2. Inter-service Network: Service mesh thực hiện một phần phân quyền dựa trên JWT
  3. Bên trong từng service: Thực hiện phân quyền trong logic domain và tầng truy cập DB

Khó khăn của phân quyền phân tán

Vì mỗi service không có sẵn toàn bộ thông tin cần thiết trong DB riêng của nó, nên để phân quyền có thể cần gọi API của service khác.
Cũng có cách cố giải quyết bằng JWT, nhưng kích thước token và chi phí xác minh trở thành vấn đề.

Tóm tắt

  • Xác thực là xác minh danh tính người dùng, phân quyền là đánh giá quyền hạn
  • Mẫu isAllowed(user, operation, resource) là cốt lõi của phân quyền
  • Triển khai bằng cách kết hợp ba mô hình RBAC, ReBAC, ABAC
  • Trong kiến trúc đơn khối, phân quyền dễ hơn nhờ truy cập một DB duy nhất
  • Trong microservices, dữ liệu phục vụ phân quyền bị phân tán nên việc triển khai phức tạp hơn

Bài viết liên quan

Chưa có bình luận nào.

Chưa có bình luận nào.