Phân quyền thông qua kiểm soát truy cập

Phân quyền là quá trình cấp quyền truy cập cho người dùng vào các phần và tài nguyên khác nhau của ứng dụng web. Một cách phổ biến để phân quyền cho người dùng là thông qua kiểm soát truy cập, trong đó quản trị viên trang web xác định những quyền cần được cấp cho người dùng và các thực thể khác để truy cập vào những tài nguyên nào.

Phân quyền không được nhầm lẫn với xác thực, là quá trình kiểm tra xem người dùng có thực sự là người mà họ tự nhận, thường được thực hiện bằng cách cung cấp thông tin đăng nhập tài khoản. Sau khi người dùng được xác thực, quá trình phân quyền vẫn phải được thực hiện trên mỗi yêu cầu, để đảm bảo rằng người dùng có quyền truy cập vào tài nguyên được yêu cầu.

Khi truy cập ứng dụng qua GraphQL, chúng ta cần xác thực xem người dùng có quyền truy cập vào các phần tử được yêu cầu trong schema hay không. Liệu logic phân quyền có nên được mã hóa trong lớp GraphQL?

Câu trả lời là không. Như tài liệu tại graphql.org đã làm rõ, logic phân quyền thuộc về lớp logic nghiệp vụ, và từ đó được GraphQL truy cập. Bằng cách này, ứng dụng có thể có một nguồn sự thật duy nhất cho việc phân quyền (tức là nguồn do WordPress cung cấp):

Gato GraphQL tôn trọng nguyên tắc này, phản ánh (và, ở tầng engine, ủy quyền cho) cơ chế phân quyền do WordPress cung cấp.

​

Các Chính Sách Kiểm Soát Truy Cập

Trong số các chính sách kiểm soát truy cập mà chúng ta có thể triển khai cho ứng dụng, hai chính sách phổ biến nhất là Kiểm Soát Truy Cập Dựa Trên Vai Trò (RBAC) và Kiểm Soát Truy Cập Dựa Trên Thuộc Tính (ABAC).

WordPress và Gato GraphQL đều hỗ trợ cả hai.

Với Kiểm Soát Truy Cập Dựa Trên Vai Trò, chúng ta cấp quyền dựa trên vai trò, sau đó gán các vai trò cho người dùng. Ví dụ, WordPress có vai trò administrator với quyền truy cập vào tất cả tài nguyên, và các vai trò editor, author, contributor, và subscriber với quyền hạn chế ở các mức độ khác nhau, chẳng hạn như có thể tạo và xuất bản bài đăng blog, chỉ tạo, hoặc chỉ đọc.

Với Kiểm Soát Truy Cập Dựa Trên Thuộc Tính, quyền được cấp dựa trên metadata có thể được gán cho các thực thể khác nhau, bao gồm người dùng, tài nguyên và các điều kiện môi trường (chẳng hạn như thời điểm trong ngày hoặc địa chỉ IP của khách truy cập). Ví dụ trong WordPress, khả năng edit_others_posts được sử dụng để xác thực xem người dùng có thể chỉnh sửa bài viết của người dùng khác hay không.

Về mặt chung, ABAC được ưa thích hơn RBAC vì nó cho phép chúng ta cấu hình quyền với kiểm soát chi tiết, và quyền đó rõ ràng trong mục tiêu của nó.

Ví dụ trong WordPress, vai trò editor có khả năng edit_others_posts, nhưng chúng ta có thể muốn cho phép một người có vai trò author chỉnh sửa bài viết của tác giả khác, mà không cần cấp cho họ toàn bộ tập hợp quyền được cấp cho editor (chẳng hạn như cũng xóa bài viết của tác giả khác). Do đó, việc cấp khả năng edit_others_posts và kiểm tra điều kiện này phù hợp hơn là kiểm tra vai trò editor.

​

Xác Định Phạm Vi Hiển Thị

Khi người dùng không có quyền truy cập vào trường được yêu cầu từ schema GraphQL, lỗi trả về sẽ là gì?

Có hai khả năng, phù hợp với phạm vi hiển thị mong muốn cho schema: công khai hoặc riêng tư.

Đối với schema công khai, schema GraphQL được hiển thị là như nhau cho tất cả người dùng, và mỗi trường mô tả những quyền nào cần thiết để truy cập nó. Khi yêu cầu một trường không thể truy cập, thông báo lỗi sẽ giải thích lý do người dùng không được cấp quyền truy cập.

Đối với schema riêng tư, schema GraphQL được tùy chỉnh cho từng người dùng, và chỉ những trường mà họ có thể truy cập mới được hiển thị. Khi yêu cầu một trường không thể truy cập, thông báo lỗi sẽ cho biết rằng trường đó không tồn tại.

​

Kiểm Soát Truy Cập Qua Giao Diện Người Dùng

Trong Gato GraphQL, các quy tắc kiểm soát truy cập được đưa vào schema tại thời điểm chạy, dưới dạng cấu hình do người dùng xác định thông qua access control lists. Bằng cách này, lớp GraphQL sẽ phản ánh ngay lập tức các thay đổi về chính sách kiểm soát truy cập, mà không cần cập nhật bất kỳ code nào hoặc biên dịch lại schema:

Quản trị viên trang web cấu hình ACL, lựa chọn:

• Các trường cần xác thực
• Một quy tắc để xác thực, trong số:
  • người dùng có phải đăng nhập không?
  • người dùng có phải đăng xuất không?
  • người dùng có phải có một vai trò nhất định không?
  • người dùng có phải có một khả năng nhất định không?
• Cấu hình cụ thể cho quy tắc:
  • vai trò nào?
  • khả năng nào?
• Phạm vi hiển thị:
  • mặc định (tức là giống với phạm vi được gán cho schema)?
  • công khai?
  • riêng tư?