什么是 ReBAC？基于关系的访问控制及示例

什么是 ReBAC？

基于关系的访问控制 (ReBAC) 根据用户和资源之间的关系来决定访问权限：alice 是文档的 owner，bob 是它的 viewer，文档 in 一个文件夹，该文件夹 belongs to 一个团队。规则针对每种关系类型只编写一次，例如“owners 可以编辑，viewers 可以读取”，每个用户通过记录在他们名下的关系获得访问权限。

ReBAC 通常回答的问题：

• 用户是否是资源的 owner？
• 用户是否是拥有该资源的项目的 member？
• 资源是否属于用户有权访问的类型？

它适用于共享是产品一部分的应用程序：文档和文件共享、协作工具、项目跟踪器、社交网络和多租户 SaaS。

ReBAC 和 Google Zanzibar

ReBAC 因 Google 关于 Zanzibar 的论文（USENIX ATC 2019）而广为人知，该系统支撑了 Google Drive、Calendar 和其他服务中的共享功能。Zanzibar 将关系存储为对象、关系和用户的元组，例如 doc:design.md#viewer@user:bob。OpenFGA 和 SpiceDB 等开源服务遵循相同的设计。在 Casbin 中，同样的事实是一行策略，即 g, bob, design.md, viewer，模型的 matcher 定义了每种关系允许的权限。

ReBAC vs RBAC vs ABAC

	访问权限来源	示例规则
RBAC	用户的角色，对所有资源相同	editors 可以编辑文档
ReBAC	用户与该特定资源的关系	文档的 owner 可以编辑它
ABAC	用户、资源和环境的属性	文档所在部门的人员可以在工作时间内读取它

为每个资源分配角色（“alice 是 doc1 的 editor”）的 RBAC 已经是 ReBAC 的一种简单形式，Casbin 在下面就是这样建模的。Choosing an access control model 通过一个示例演示了每种模型并进行了并列比较。

Casbin 中的 ReBAC

Casbin 通过以下方式对 ReBAC 进行建模：

• 用户–资源–角色 关系：“用户 U 在资源 O 上拥有角色 R”（例如 alice 在 doc1 上是 collaborator）。
• 资源–类型 关系：“资源 O 属于类型 T”（例如 doc1 属于类型 doc）。

权限则是“角色 R 可以对类型 T 执行操作 A”；如果用户在属于类型 T 的资源上拥有 R，则该用户获得权限。示例模型：

[request_definition]
r = sub, obj, act

[policy_definition]
p = role, obj_type, act

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

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

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

# Permission definition: The "collaborator" role can read files of type "doc"
p, collaborator, doc, read

# User-Resource-Role Relationship: alice is a collaborator of doc1
g, alice, doc1, collaborator

# Resource-Type Relationship: doc1 is of type "doc"
g2, doc1, doc

因此：用户必须在资源上拥有正确的角色，且资源必须匹配权限规则中的类型。Casbin 结合 g（用户–资源–角色）、g2（资源–类型）和 p（角色–类型–操作）来决定访问权限。

FAQ

使用 ReBAC 是否需要类似 Zanzibar 的服务？ 不需要。如果关系适合存储在应用程序数据库中，且检查在服务内部进行，那么像 Casbin 这样的库就足够了。当许多服务必须共享同一个关系存储时，专用服务才有意义；参见 Casbin vs. OpenFGA。

我可以不写代码就尝试这个模型吗？ 可以。请在 online editor 中选择 ReBAC 示例。

相关模型

• RBAC
• ABAC
• Access control models compared
• Casbin vs. OpenFGA