Understanding How Casbin Matching Works in Detail

Trong bài viết này, tôi sẽ giải thích thiết kế và triển khai RBAC sử dụng thư viện Casbin. Đối với một nền tảng SaaS xử lý nhiều cấu trúc tài nguyên và vai trò kế thừa quyền từ cấp cao hơn, Casbin cung cấp một giải pháp thay thế hiệu suất cao để xem xét.

Giới thiệu về RBAC

RBAC là phương pháp hạn chế truy cập vào tài nguyên dựa trên vai trò mà cá nhân giữ. Để hiểu rõ hơn cách thức hoạt động của RBAC phân cấp, hãy xem xét hệ thống RBAC của Azure trong phần tiếp theo và sau đó thử triển khai một hệ thống tương tự.

Hiểu về RBAC Phân cấp của Azure

Cấu trúc phân cấp Azure

Có một vai trò gọi là Chủ sở hữu cho tất cả các tài nguyên trong Azure. Giả sử nếu tôi được gán vai trò Chủ sở hữu ở cấp độ đăng ký, điều đó có nghĩa là tôi là Chủ sở hữu của tất cả các nhóm tài nguyên và tài nguyên dưới đăng ký đó. Nếu tôi có vai trò Chủ sở hữu ở cấp độ nhóm tài nguyên, thì tôi là Chủ sở hữu của tất cả các tài nguyên dưới nhóm tài nguyên đó.

Hình ảnh này cho thấy tôi có quyền truy cập Chủ sở hữu ở cấp độ đăng ký. Chủ sở hữu Đăng ký

Khi tôi kiểm tra IAM của một Nhóm Tài nguyên dưới Đăng ký này, bạn có thể thấy rằng tôi đã kế thừa quyền truy cập Chủ sở hữu từ đăng ký. Chủ sở hữu Nhóm Tài nguyên

Vậy, đây là cách RBAC của Azure có cấu trúc phân cấp. Hầu hết phần mềm doanh nghiệp sử dụng RBAC phân cấp do bản chất phân cấp của các mức tài nguyên. Trong hướng dẫn này, chúng ta sẽ thử triển khai một hệ thống tương tự sử dụng Casbin.

Casbin hoạt động như thế nào?

Trước khi đi vào triển khai, điều quan trọng là phải hiểu Casbin là gì và nó hoạt động ở mức độ cao như thế nào. Sự hiểu biết này là cần thiết bởi vì mỗi hệ thống Kiểm soát truy cập dựa trên vai trò (RBAC) có thể khác nhau dựa trên các yêu cầu cụ thể. Bằng cách nắm bắt cách hoạt động của Casbin, chúng ta có thể tinh chỉnh mô hình một cách hiệu quả.

ACL là gì?

ACL là viết tắt của Access Control List. Đây là một phương pháp mà người dùng được ánh xạ đến các hành động và hành động đến các tài nguyên.

Định nghĩa mô hình

Hãy xem xét một ví dụ đơn giản về mô hình ACL.

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

request_definition là mẫu truy vấn của hệ thống. Ví dụ, một yêu cầu alice, write, data1 có thể được hiểu là "Đối tượng Alice có thể thực hiện hành động 'write' trên đối tượng 'data1' không?".
policy_definition là mẫu gán quyền của hệ thống. Ví dụ, bằng cách tạo một chính sách alice, write, data1, bạn đang gán quyền cho đối tượng Alice thực hiện hành động 'write' trên đối tượng 'data1'.
policy_effect định nghĩa hiệu ứng của chính sách.
Trong phần matchers, yêu cầu được so khớp với chính sách bằng các điều kiện r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Bây giờ hãy kiểm tra mô hình trên trình soạn thảo Casbin

Mở trình soạn thảo và dán mô hình trên vào phần Model editor.

Dán phần sau vào trình soạn thảo Chính sách:

p, alice, read, data1
p, bob, write, data2

và phần sau vào trình soạn thảo Yêu cầu:

alice, read, data1

Kết quả sẽ là:

true

Biểu diễn trực quan của mô hình ACL, chính sách và yêu cầu khớp nhau

acl

RBAC là gì?

RBAC là viết tắt của Role-Based Access Control. Trong RBAC, một người dùng được gán một vai trò cho một tài nguyên, và một vai trò có thể chứa các hành động tùy ý. Sau đó, yêu cầu kiểm tra xem người dùng có quyền thực hiện hành động trên tài nguyên đó hay không.

Định nghĩa mô hình

Hãy xem xét một mô hình RBAC đơn giản:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj

role_definition là một trình xây dựng quan hệ đồ thị sử dụng một Đồ thị để so sánh đối tượng yêu cầu với đối tượng chính sách.

Bây giờ hãy kiểm tra mô hình trên trình soạn thảo Casbin

Mở trình soạn thảo và dán mô hình trên vào Trình soạn thảo Mô hình.

Dán nội dung sau vào Trình soạn thảo Chính sách:

p, alice, reader, data1
p, bob, owner, data2

g, reader, read
g, owner, read
g, owner, write

và nội dung sau vào Trình soạn thảo Yêu cầu:

alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1

Kết quả sẽ là:

true
false
true
true
false

Biểu diễn trực quan của mô hình RBAC, chính sách và việc so khớp yêu cầu

rbac

Bảng g - Ánh xạ vai trò đến hành động có một ánh xạ đồ thị ánh xạ vai trò đến hành động. Biểu đồ này có thể được mã hóa dưới dạng danh sách các cạnh, như thể hiện trong chính sách, đây là một cách phổ biến để biểu diễn một Biểu đồ:

g, reader, read
g, owner, read
g, owner, write

thông tin

p chỉ một chính sách bình thường có thể so sánh bằng cách sử dụng toán tử ==. g là một hàm so sánh dựa trên Biểu đồ. Bạn có thể định nghĩa nhiều bộ so sánh Biểu đồ bằng cách thêm hậu tố số như g, g2, g3, ... và cứ thế.

Hierarchical RBAC là gì?

Trong Hierarchical RBAC, có nhiều hơn một loại tài nguyên và có mối quan hệ kế thừa giữa các loại tài nguyên. Ví dụ, "subscription" là một loại và "resourceGroup" là một loại khác. Một sub1 thuộc loại Subscription có thể chứa nhiều resourceGroups (rg1, rg2) thuộc loại ResourceGroup.

Tương tự như cấu trúc hệ thống tài nguyên, sẽ có hai loại vai trò và hành động: Vai trò và hành động của Subscription, và vai trò và hành động của ResourceGroup. Có một mối quan hệ tùy ý giữa vai trò Subscription và vai trò ResourceGroup. Ví dụ, hãy xem xét vai trò Đăng ký sub-owner. Vai trò này được kế thừa bởi vai trò Nhóm Tài nguyên rg-owner, điều đó có nghĩa là nếu tôi được gán vai trò sub-owner trên Đăng ký sub1, thì tôi tự động cũng nhận được vai trò rg-owner trên rg1 và rg2.

Định nghĩa mô hình

Hãy lấy một ví dụ đơn giản về mô hình Hierarchical RBAC:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && g2(p.obj, r.obj)

role_definition là một trình xây dựng quan hệ đồ thị sử dụng Đồ thị để so sánh đối tượng yêu cầu với đối tượng chính sách.

Bây giờ hãy kiểm tra mô hình trên trình soạn thảo Casbin

Mở trình soạn thảo và dán mô hình trên vào Trình soạn thảo Mô hình.

Dán nội dung sau vào Trình soạn thảo Chính sách:

p, alice, sub-reader, sub1
p, bob, rg-owner, rg2

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Và dán nội dung sau vào Trình soạn thảo Yêu cầu:

alice, rg-read, rg1

Kết quả sẽ là:

true

Biểu diễn trực quan của mô hình RBAC, chính sách và khớp yêu cầu

hrbac

Bảng g - Ánh xạ vai trò đến (Hành động, Vai trò) có một biểu đồ ánh xạ vai trò đến ánh xạ hành động, vai trò. Biểu đồ này có thể được mã hóa thành một danh sách các cạnh, như được thể hiện trong chính sách, đây là một cách phổ biến để biểu diễn một biểu đồ:

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

Bảng g2 - Ánh xạ Sub đến RG có một biểu đồ ánh xạ đăng ký đến nhóm tài nguyên:

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Biểu diễn trực quan khớp chủ thể

hrbac-sub-match

Biểu diễn trực quan khớp hành động

hrbac-act-match

Biểu diễn trực quan khớp đối tượng

hrbac-obj-match

thông tin

Khi một yêu cầu được gửi đến Casbin, quá trình so khớp này diễn ra cho tất cả các chính sách. Nếu có ít nhất một chính sách khớp, thì kết quả của yêu cầu là đúng. Nếu không có chính sách nào khớp với yêu cầu, thì kết quả là sai.

Kết luận

Trong hướng dẫn này, chúng ta đã tìm hiểu về cách các mô hình ủy quyền khác nhau hoạt động và cách chúng có thể được mô hình hóa bằng Casbin. Trong phần thứ hai của hướng dẫn này, chúng ta sẽ triển khai điều này trong một ứng dụng Spring Boot Demo và bảo mật các API bằng Casbin.