跳转至主要内容

Understanding How Casbin Matching Works in Detail

在这篇文章中，我将解释如何使用Casbin库设计和实现RBAC。 对于处理多个资源层次结构和从高级别继承权限的SaaS平台，Casbin提供了一个性能良好的替代方案。

RBAC简介​

RBAC是一种基于个人角色限制对资源访问的方法。 为了更好地理解分层RBAC是如何工作的，让我们在下一节看一下Azure的RBAC系统，然后尝试实现一个类似的系统。

理解Azure的分层RBAC​

Azure Hierarchy

Azure的所有资源都有一个名为Owner的角色。 假设如果我在订阅级别被分配了Owner角色，那就意味着我是该订阅下所有资源组和资源的Owner。 如果我在资源组级别拥有Owner，那么我就是该资源组下所有资源的Owner。

这张图片显示我在订阅级别拥有Owner访问权限。 Subscription Owner

当我检查这个订阅下的一个资源组的IAM时，你可以看到我从订阅中继承了Owner访问权限。 RG Owner

所以，这就是Azure的RBAC是如何分层的。 大多数企业软件都使用分层RBAC，因为资源级别的分层性质。 在这个教程中，我们将尝试使用Casbin实现一个类似的系统。

Casbin是如何工作的？​

在深入实现之前，理解Casbin是什么以及它在高层次上如何运作是很重要的。 这种理解是必要的，因为每个基于角色的访问控制（RBAC）系统可能会根据特定的需求有所不同。 通过掌握Casbin的工作原理，我们可以有效地调整模型。

什么是ACL？​

ACL代表访问控制列表。 这是一种将用户映射到操作和操作映射到资源的方法。

模型定义​

让我们考虑一个简单的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

  1. request_definition是系统的查询模板。 例如，一个请求alice, write, data1可以被解释为"主体Alice能否对对象'data1'执行'write'操作？"。

  2. policy_definition是系统的分配模板。 例如，通过创建一个策略alice, write, data1，你就赋予了主体Alice在对象'data1'上执行'write'操作的权限。

  3. policy_effect定义了策略的效果。

  4. 在matchers部分，请求使用条件r.sub == p.sub && r.obj == p.obj && r.act == p.act与策略进行匹配。

现在让我们在Casbin编辑器上测试模型​

打开编辑器并将上述模型粘贴到模型编辑器中。

在策略编辑器中粘贴以下内容：

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

在请求编辑器中粘贴以下内容：

alice, read, data1

结果将是：

true

ACL模型、策略和请求匹配的视觉表示​

acl

什么是RBAC？​

RBAC代表基于角色的访问控制。 在RBAC中，用户被分配一个资源的角色，一个角色可以包含任意的操作。 然后请求检查用户是否有权限在资源上执行操作。

模型定义​

让我们考虑一个简单的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) && r.obj == p.obj
  1. role_definition是一个图关系构建器，它使用图来比较请求对象和策略对象。

现在让我们在Casbin编辑器上测试模型​

打开编辑器并将上述模型粘贴到模型编辑器中。

在策略编辑器中粘贴以下内容：

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

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

在请求编辑器中粘贴以下内容：

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

结果将是：

true
false
true
true
false

RBAC模型、策略和请求匹配的视觉表示​

rbac

g - Role to action mapping表有一个图映射角色到操作。 这个图可以被编码为一系列的边，如在策略中所示，这是表示图的一种常见方式：

g, reader, read
g, owner, read
g, owner, write
信息

p表示一个可以使用==操作符进行比较的普通策略。 g是一个基于图的比较函数。 你可以通过添加数字后缀如g, g2, g3, ...等来定义多个图比较器。

什么是分层RBAC？​

在分层RBAC中，有多种类型的资源，并且资源类型之间存在继承关系。 例如，“订阅”是一种类型，“资源组”是另一种类型。 类型为订阅的sub1可以包含多个类型为资源组的资源组（rg1，rg2）。

与资源层次结构类似，将有两种类型的角色和操作：订阅角色和操作，以及资源组角色和操作。 订阅角色和资源组角色之间存在任意关系。 例如，考虑一个订阅角色sub-owner。 这个角色被一个资源组角色rg-owner继承，这意味着如果我在订阅sub1上被分配了sub-owner角色，那么我自动也获得了rg1和rg2上的rg-owner角色。

模型定义​

让我们以分层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)
  1. role_definition是一个图关系构建器，它使用图来比较请求对象和策略对象。

现在让我们在Casbin编辑器上测试这个模型​

打开编辑器并将上述模型粘贴到模型编辑器中。

在策略编辑器中粘贴以下内容：

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

并在请求编辑器中粘贴以下内容：

alice, rg-read, rg1

结果将是：

true

RBAC模型、策略和请求匹配的视觉表示​

hrbac

g - 角色到（操作，角色）映射表有一个图映射角色到操作，角色映射。 这个图可以被编码为一系列的边，如策略中所示，这是表示图的常见方式：

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

g2 - 订阅到资源组映射表有一个图映射订阅到资源组：

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

主题匹配视觉表示​

hrbac-sub-match

操作匹配视觉表示​

hrbac-act-match

对象匹配视觉表示​

hrbac-obj-match

信息

当一个请求提交给Casbin时，所有的策略都会进行这种匹配。 如果至少有一个策略匹配，那么请求的结果为真。 如果没有策略匹配请求，那么结果为假。

结论​

在本教程中，我们学习了不同的授权模型是如何工作的，以及如何使用Casbin对其进行建模。 在本教程的第二部分，我们将在一个演示的Spring Boot应用程序中实现这一点，并使用Casbin保护API。