Bỏ qua đến nội dung chính

· Đọc trong 1 phút
Yang Luo

2024 was the year AI agents went from demos to production. With the Model Context Protocol (MCP) gaining adoption from Google, OpenAI, Microsoft, and countless others, we're seeing a fundamental shift in how applications interact with external services. And with that shift comes a whole new set of authorization challenges that we at Casbin have been thinking about.

· Đọc trong 1 phút
Aravinda Kumar

In this post, I will explain the design and implementation of RBAC using the Casbin library. For a SaaS platform dealing with multiple resource hierarchies and roles that inherit permissions from higher levels, Casbin provides a performant alternative to consider.

Introduction to RBAC​

RBAC is a method of restricting access to resources based on the roles that individuals hold. To better understand how hierarchical RBAC works, let's take a look at Azure's RBAC system in the next section and then attempt to implement a similar system.

Understanding Azure's Hierarchical RBAC​

Azure Hierarchy

There is a role called Owner for all resources in Azure. Suppose if I have the Owner role assigned to me at the subscription level, that means I am the Owner of all the resource groups and resources under that subscription. If I have Owner at the resource group level, then I am the Owner of all the resources under that resource group.

This image shows that I have Owner access at the subscription level. Subscription Owner

When I check the IAM of a Resource Group under this Subscription, you can see that I have inherited Owner access from the subscription. RG Owner

So, this is how Azure's RBAC is hierarchical. Most enterprise software uses hierarchical RBAC because of the hierarchical nature of the resource levels. In this tutorial, we'll try to implement a similar system using Casbin.

How Does Casbin Work?​

Before diving into the implementation, it is important to understand what Casbin is and how it functions at a high level. This understanding is necessary because each Role-Based Access Control (RBAC) system may vary based on specific requirements. By grasping the workings of Casbin, we can effectively fine-tune the model.

What is ACL?​

ACL stands for Access Control List. It is a method in which users are mapped to actions and actions to resources.

The model definition​

Let's consider a simple example of an ACL model.

[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

  1. The request_definition is the query template of the system. For example, a request alice, write, data1 can be interpreted as "Can subject Alice perform the action 'write' on object 'data1'?".

  2. The policy_definition is the assignment template of the system. For example, by creating a policy alice, write, data1, you are assigning permission to subject Alice to perform the action 'write' on object 'data1'.

  3. The policy_effect defines the effect of the policy.

  4. In the matchers section, the request is matched with the policy using the conditions r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Now let's test the model on the Casbin editor​

Open the editor and paste the above model in the Model editor.

Paste the following in the Policy editor:

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

and the following in the Request editor:

alice, read, data1

The result will be:

true

Visual representation of the ACL model, policy, and request matching​

acl

What is RBAC?​

RBAC stands for Role-Based Access Control. In RBAC, a user is assigned a role for a resource, and a role can contain arbitrary actions. The request then checks if the user has the permission to perform the action on the resource.

The model definition​

Let's consider a simple example RBAC model:

[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
  1. The role_definition is a graph relation builder that uses a Graph to compare the request object with the policy object.

Now let's test the model on Casbin editor​

Open the editor and paste the above model in the Model editor.

Paste the following in the Policy editor:

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

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

and the following in the Request editor:

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

The result will be:

true
false
true
true
false

Visual representation of the RBAC model, policy, and request matching​

rbac

The g - Role to action mapping table has a Graph mapping the role to action. This Graph can be coded as a list of edges, as shown in the policy which is a common way of representing a Graph:

g, reader, read
g, owner, read
g, owner, write
thông tin

p indicates a normal policy that can be compared using the == operator. g is a Graph-based comparison function. You can define multiple Graph comparators by adding a numerical suffix like g, g2, g3, ... and so on.

What is Hierarchical RBAC?​

In Hierarchical RBAC, there are more than one type of resources and there is an inheritance relationship between the resource types. For example, "subscription" is one type and "resourceGroup" is another type. A sub1 of type Subscription can contain multiple resourceGroups (rg1, rg2) of type ResourceGroup.

Similar to the resource hierarchy, there will be two types of roles and actions: Subscription roles and actions, and ResourceGroup roles and actions. There is an arbitrary relationship between the Subscription role and ResourceGroup role. For example, consider a Subscription Role sub-owner. This role is inherited by a ResourceGroup Role rg-owner, which means that if I am assigned the sub-owner role on Subscription sub1, then I automatically also get the rg-owner role on rg1 and rg2.

The model definition​

Let's take a simple example of the Hierarchical RBAC model:

[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)
  1. The role_definition is a graph relation builder which uses a Graph to compare the request object with the policy object.

Now let's test the model on the Casbin editor​

Open the editor and paste the above model in the Model editor.

Paste the following in the Policy editor:

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

And paste the following in the Request editor:

alice, rg-read, rg1

The result will be:

true

Visual representation of the RBAC model, policy, and request matching​

hrbac

The g - Role to (Action, Role) Mapping table has a graph mapping the role to the action, role mapping. This graph can be coded as a list of edges, as shown in the policy, which is a common way of representing a graph:

// 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

The g2 - Sub to RG Mapping table has a graph mapping subscription to resourceGroup:

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

Subject Matching Visual representation​

hrbac-sub-match

Action Matching Visual representation​

hrbac-act-match

Object Matching Visual representation​

hrbac-obj-match

thông tin

When a request is submitted to Casbin, this matching happens for all the policies. If at least one policy matches, then the result of the request is true. If no policy matches the request, then the result is false.

Conclusion​

In this tutorial, we learned about how different authorization models work and how they can be modeled using Casbin. In the second part of this tutorial, we will implement this in a demo Spring Boot Application and secure the APIs using Casbin.

· Đọc trong 1 phút
Rushikesh Tote

Giới thiệu​

APISIX là một cổng API đáng tin cậy, hiệu suất cao và có khả năng mở rộng dựa trên Nginx và etcd. Nó là một dự án nguồn mở của Quỹ Phần mềm Apache. Ngoài ra, điều làm cho APISIX trở nên tuyệt vời là sự hỗ trợ của nhiều plugin tích hợp đỉnh cao có thể được sử dụng để triển khai các tính năng như xác thực, giám sát, định tuyến, v.v. Và thực tế là các plugin trong APISIX được tải lại nóng (không cần khởi động lại) làm cho nó rất linh hoạt.

Tuy nhiên, khi sử dụng APISIX, có thể có những tình huống mà bạn muốn thêm logic ủy quyền phức tạp vào ứng dụng của mình. Đây là nơi mà authz-casbin có thể giúp bạn, authz-casbin là một plugin của APISIX dựa trên Lua Casbin cho phép ủy quyền mạnh mẽ dựa trên nhiều mô hình kiểm soát truy cập khác nhau. Casbin là một thư viện ủy quyền hỗ trợ các mô hình kiểm soát truy cập như ACL, RBAC, ABAC. Ban đầu được viết bằng Go, nó đã được chuyển sang nhiều ngôn ngữ khác và Lua Casbin là việc triển khai Lua của Casbin. Sự phát triển của authz-casbin bắt đầu khi chúng tôi đề xuất một plugin mới cho ủy quyền trong kho lưu trữ APISIX (#4674) mà các thành viên chính đã đồng ý. Và sau những đánh giá hữu ích dẫn đến một số thay đổi và cải tiến lớn, PR (#4710) cuối cùng đã được hợp nhất.

Trong bài blog này, chúng tôi sẽ sử dụng plugin authz-casbin để chỉ ra cách bạn có thể triển khai một mô hình ủy quyền dựa trên Kiểm soát Truy cập Dựa trên Vai trò (RBAC) trong APISIX.

LƯU Ý: Bạn sẽ cần sử dụng một số plugin khác hoặc quy trình làm việc tùy chỉnh để xác thực người dùng vì Casbin chỉ thực hiện ủy quyền, không phải xác thực.

Tạo một mô hình​

Plugin sử dụng ba tham số để ủy quyền bất kỳ yêu cầu nào - chủ thể, đối tượng và hành động. Ở đây, chủ thể là giá trị của tiêu đề tên người dùng, có thể là một cái gì đó như [username: alice]. Sau đó, đối tượng là đường dẫn URL đang được truy cập và hành động là phương thức yêu cầu đang được sử dụng.

Giả sử chúng ta muốn tạo một mô hình với ba tài nguyên tại các đường dẫn - /`\`, /res1\ và `/res2`. Và chúng ta muốn có một mô hình như thế này:

hình ảnh

Điều này có nghĩa là tất cả người dùng (*`\`) ví dụ như jack\ có thể truy cập trang chủ (/`\`). Và người dùng có quyền admin\ như alice`\` và bob\ có thể truy cập tất cả các trang và tài nguyên (như res1`\` và res2\). Ngoài ra, hãy giới hạn người dùng không có bất kỳ quyền admin nào chỉ sử dụng phương thức yêu cầu `GET`. Đối với kịch bản này, chúng ta có thể định nghĩa mô hình như sau:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

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

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

Tạo một chính sách​

Từ tình huống trên, chính sách sẽ là:

p, *, /, GET
p, admin, *, *
g, alice, admin
g, bob, admin

Bộ so khớp từ mô hình có nghĩa là:

  1. (g(r.sub, p.sub) || keyMatch(r.sub, p.sub)): Hoặc là chủ thể của yêu cầu có một vai trò như chủ thể của chính sách hoặc chủ thể của yêu cầu khớp với chủ thể của chính sách trong keyMatch. keyMatch là hàm tích hợp sẵn trong Lua Casbin, bạn có thể xem mô tả của hàm và nhiều hàm khác có thể hữu ích tại đây.
  2. keyMatch(r.obj, p.obj): Đối tượng của yêu cầu khớp với đối tượng của chính sách (đường dẫn URL ở đây).
  3. keyMatch(r.act, p.act): Hành động của yêu cầu khớp với hành động của chính sách (phương thức yêu cầu HTTP ở đây).

Kích hoạt plugin trên tuyến đường​

Sau khi bạn đã tạo mô hình và chính sách, bạn có thể kích hoạt nó trên một tuyến đường bằng cách sử dụng APISIX Admin API. Để kích hoạt nó sử dụng đường dẫn tệp mô hình và chính sách:

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "model_path": "/path/to/model.conf",
            "policy_path": "/path/to/policy.csv",
            "username": "username"
        }
    },
    "upstream": {
        "nodes": {
            "127.0.0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}'

Ở đây, trường username là tên tiêu đề mà bạn sẽ sử dụng để truyền vào chủ thể. Ví dụ, nếu bạn sẽ truyền tiêu đề username là user: alice`\`, bạn sẽ sử dụng "username": "user"\.

Để sử dụng văn bản mô hình/chính sách thay vì tệp, bạn có thể sử dụng các trường model và policy thay thế:

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "model": "[request_definition]
            r = sub, obj, act

            [policy_definition]
            p = sub, obj, act

            [role_definition]
            g = _, _

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

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

            "policy": "p, *, /, GET
            p, admin, *, *
            g, alice, admin
            g, bob, admin",

            "username": "username"
        }
    },
    "upstream": {
        "nodes": {
            "127.0.0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}'

Kích hoạt plugin sử dụng mô hình/chính sách toàn cục​

Có thể có những tình huống mà bạn muốn sử dụng một cấu hình mô hình và chính sách duy nhất trên nhiều tuyến. Bạn có thể làm điều đó bằng cách gửi một yêu cầu PUT để thêm cấu hình mô hình và chính sách vào siêu dữ liệu của plugin bằng:

curl http://127.0.0.1:9080/apisix/admin/plugin_metadata/authz-casbin -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -i -X PUT -d '
{
"model": "[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

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

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

"policy": "p, *, /, GET
p, admin, *, *
g, alice, admin
g, bob, admin"
}'

Và sau đó để kích hoạt cấu hình giống nhau trên một tuyến đường, gửi một yêu cầu sử dụng Admin API:

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "username": "username"
        }
    },
    "upstream": {
        "nodes": {
            "127.0.0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/route1/*"
}'

Điều này sẽ thêm cấu hình siêu dữ liệu plugin vào tuyến đường. Bạn cũng có thể dễ dàng cập nhật cấu hình siêu dữ liệu plugin bằng cách gửi lại yêu cầu đến siêu dữ liệu của plugin với cấu hình mô hình và chính sách đã cập nhật, plugin sẽ tự động cập nhật tất cả các tuyến đường sử dụng siêu dữ liệu plugin.

Trường hợp sử dụng​

  • Trường hợp sử dụng chính của plugin này sẽ là trong việc thực hiện ủy quyền trong các API của bạn. Bạn có thể dễ dàng thêm plugin này vào bất kỳ tuyến đường API nào mà bạn đang sử dụng với mô hình ủy quyền và cấu hình chính sách của mình.
  • Nếu bạn muốn có một mô hình ủy quyền duy nhất cho tất cả các API của mình, bạn có thể sử dụng phương pháp mô hình/chính sách toàn cầu. Điều này giúp cập nhật chính sách dễ dàng cho tất cả các tuyến đường, vì bạn chỉ cần cập nhật siêu dữ liệu trong etcd.
  • Trong khi đó, nếu bạn muốn sử dụng một mô hình khác nhau cho mỗi tuyến đường khác nhau, bạn có thể sử dụng phương pháp tuyến đường. Điều này rất hữu ích khi các tuyến API khác nhau có các tập hợp quyền người dùng khác nhau. Bạn cũng có thể sử dụng điều này khi bạn đang xử lý các chính sách lớn hơn, vì nó sẽ làm cho việc ủy quyền nhanh hơn khi được lọc vào nhiều tuyến.

· Đọc trong 1 phút
Casbin

Hôm nay, chúng tôi hân hạnh thông báo rằng người sáng lập Casbin, Yang Luo đã được trao giải "Google Open Source Peer Bonus winners" cho công việc của anh ấy trên Casbin, Npcap và Nmap vào quý 3 năm 2019.

ospb

Thư trao giải gốc có thể được truy cập tại đây.

Chương trình Google Open Source Peer Bonus được mô tả như sau:

Cũng giống như một Google Peer Bonus được sử dụng để vinh danh một đồng nghiệp Google đã vượt quá mong đợi, một Open Source Peer Bonus vinh danh những người ngoài có đóng góp xuất sắc cho nguồn mở.

Thông báo trao giải năm 2019 có sẵn tại:

https://opensource.googleblog.com/2020/01/announcing-2019-second-cycle-google.html

Yang và Casbin được liệt kê cùng với các nhà phát triển và dự án nguồn mở có tác động liên quan như Git, TensorFlow, V8, CPython, LLVM, các dự án Apache, Angular hay Jenkins.

Chúng tôi rất vui khi thấy Casbin được công nhận theo cách này cho đóng góp của mình vào bảo mật nguồn mở và đám mây!

Cảm ơn vì đã sử dụng Casbin!

· Đọc trong 1 phút
Yang Luo

Hôm nay, chúng tôi đã di chuyển tài liệu của Casbin từ GitHub Wiki sang phần Docs của trang web này, Docusaurus cung cấp nhiều tính năng tuyệt vời như kiểu Markdown tốt hơn, tìm kiếm toàn văn, phiên bản hóa, dịch thuật.

Tài liệu chưa hoàn hảo và vẫn cần điều chỉnh. Mã nguồn được lưu trữ

Bất kỳ đóng góp hoặc đề xuất nào cũng đều được hoan nghênh!

· Đọc trong 1 phút
Zixuan Liu

Hôm nay, chúng tôi đã thành công trong việc chuyển Casbin sang Node.js, được đặt tên là:

node-Casbin chia sẻ cách sử dụng và API tương tự Các middleware cho Express, Koa2 và Egg.js đã sẵn sàng Bộ chuyển đổi lưu trữ cho Sequelize cũng đã được chuẩn bị.

Hy vọng nó có thể đáp ứng tốt nhu cầu của bạn :)

GitHub: https://github.com/casbin/node-casbin

· Đọc trong 1 phút
Helong Zhang

Một số khách hàng của chúng tôi hỏi liệu Casbin có thể được sử dụng như một dịch vụ thay vì một thư viện. Câu trả lời là CÓ. Hôm nay, chúng tôi đã khởi chạy dự án Casbin Server như một giải pháp cụ thể cho Kiểm soát Truy cập như một Dịch vụ.

Máy chủ Casbin đang được phát triển tích cực bởi nhóm chính của chúng tôi. Nó có một số tính năng:

  • Được phát triển hoàn toàn bằng Golang.
  • Có thể quản lý hàng ngàn phiên bản Casbin, giúp bạn chuyển đổi logic thực thi chính sách từ nhiều dịch vụ vào một Máy chủ Casbin.
  • gRPC được sử dụng để giao tiếp với Máy chủ Casbin. Chúng tôi cũng xem xét việc thêm hỗ trợ RESTful trong tương lai gần.
  • Một cổng quản trị web thân thiện được cung cấp cho các quản trị viên không phải là nhà phát triển để quản lý tất cả các chi tiết như phiên bản Casbin, mô hình, lưu trữ chính sách và cân bằng tải.

Mã nguồn được lưu trữ trên GitHub: https://github.com/casbin/casbin-server

Bất kỳ vấn đề hoặc yêu cầu kéo nào cũng đều được hoan nghênh :)