CASBIN学习笔记

权限

RBAC,ABAC,REBAC访问权限控制模型-CSDN博客

ACL

ACL是关联与每个对象的权限列表，记录哪些主题（用户，组或进程）能以何种方式（如读写执行）访问该对象

Linux默认文件系统权限基于所有者、所属组和其他用户三元组模型，本质上是一种简化的ACL形式

Linux原生不提供完整的RBAC支持，通过配置/etc/sudoers，将用户组（如sysadmin）与特定命令绑定，可以模拟角色权限分离：

REBAC

除了下面提到的外还有REBAC relationship based access control，基于关系访问的控制。基于用户之间的关系（如“同事”、“下属”、“项目成员”）或用户与资源之间的关系（如“文件所有者”、“群组成员”）来决定访问权限。

优点：适合社交网络写作平台等场景。高强度动态，权限随关系变化自动调整。可组合性强，能通过关系链进行间接权限。支持继承与传递，可定义关系的传递性。

缺点：关系管理复杂：大规模关系网络维护和查询成本高。权限有蔓延风险，关系链过程可能导致意外授权。性能挑战大，关系路径查找，在大数据量下可能变慢。权限来源不直观，难以追溯。

ABAC

attribute-based access control

基于主体（用户）、客体（资源）、操作和环境的属性，通过策略规则动态判断是否允许访问。

优点：高度灵活、支持上下文相关的访问控制（如部门经理在工作时间可审批报销）。能实现非常精细的权限策略。动态决策，能够根据实时环境（时间，IP，设备安全等级）调整访问权限。可扩展性强。

缺点：复杂性高，策略和维护难度大，需要专门的策略语言（如XACML）。每次访问都需要评估多个属性，可能影响性能。当访问被拒绝时难以快速定位额是哪个属性导致的。实施成本高，需要策略决策点PDP、策略执行点PEP等架构支持。

RBAC+ABAC

RBAC提供基础权限框架，用户通过角色获得通常情况下的权限。ABAC作为策略过滤器或增强层：在角色权限的基础上，根据上文属性（时间地点，设备，资源熟悉）动态决定是否允许访问。

协作平台（如 Google Drive / Notion）中的文件共享

REBAC 层面：

文件 A 属于“项目组X”
用户 B 是“项目组X”的成员 → 因此 B 可以查看文件 A
用户 C 是 B 的直接上级 → C 可以“查看下属的所有工作文档”（通过组织关系链）
ABAC 增强规则：

如果文件标记为 classification=sensitive（敏感），则：
必须使用 公司注册设备 才能下载
禁止在 非工作时间（22:00–6:00） 访问
访问者必须具有 security_level>=3 的属性
所有访问操作必须从 企业网络或VPN 内发起

简介

Casbin | Golang 中文学习文档

CASbin是一个高效的访问控制库，本身采用go语言进行开发，同时也支持其他主流的语言。

Casbin仅仅是一个访问控制框架，只负责访问控制，访问认证方面的逻辑不由Casbin负责，它仅仅存储用户与角色之间的映射关系。支持以下访问控制模型。

1. ACL（访问控制列表）
2. RBAC（基于角色的访问控制）
3. ABAC（基于属性的访问控制）
4. 拒绝优先：支持语序和拒绝授权，拒绝优先于允许
5. 优先级：策略规则按照先后次序确定优先级，类似于防火墙规则

工作原理

在Casbin中，访问控制模型被抽象为基于PERM的配置文件，PERM指，策略，效果，请求，匹配。在项目修改授权机制时，只需要简单修改配置文件即可。

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

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

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

这是一个最简单的访问控制模型

策略

p指的是policy，不能用其他字符替代，sub指的是subject，为策略对象。act即action，指的是行为

p = sub, obj, act

也可以有第四个字段eft，如果省略默认eft为allow。

p=sub, obj, act, eft

这一行定义只是描述了policy该如何书写，并非具体的策略定义。下面是一个具体的policy例子

p, jojo, cake, eat

p代表了这是一条策略规则定义，jojo即策略主体，cake即策略对象，eat即行为，完整意思为主体jojo能对对象cake进行行为eat。具体的策略规则并不会出现在模型文件中，会有专门的policy文件或者数据库来进行策略存储。

请求

[request_definition]
r = sub, obj, act说

r即指request，不能用其他字符代替，sub即subject，指请求主体，obj即object，指请求对象，act即action，指的是请求行为。一般情况下请求定义与策略定义字段名都一致。请求部分并不由casbin负责，这由开发者自己决定什么是请求主体，什么是请求对象，casbin只需要负责根据传入的字段来进行访问控制。

匹配

在配置文件中，匹配定义部分为

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

m指matcher，不能使用其他字符代替，其后就是相应的匹配规则，上述就是一个简单的布尔表达式，其意为传入的请求的所有字段都与策略规则的字段全部相同就匹配，当然它也可以是通配符或者表达力更强的正则表达式。

除此之外，matcher还支持in语法，例如

[matchers]
m = r.sub in ("root","admin")

也可以是

[matchers]
m = r.sub.Name in (r.obj.Admins)

e.Enforce(Sub{Name: "alice"}, Obj{Name: "a book", Admins: []interface{}{"alice", "bob"}})

在进行匹配时，Casbin不会进行类型检查，而是将其作为interface进行==检查是否相等。

效果

效果定义部分对匹配结果再次作出逻辑组合判断，在配置文件中，效果定义部分为

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

e即指effect，不能使用其他字符代替。 some 量词判断是否存在一条策略规则满足匹配器。 any 量词则判断是否所有的策略规则都满足匹配器 。

some(where (p.eft == allow))

这一条规则意为在匹配结果中有一条结果allow，那么最终结果就为allow。

e = !some(where (p.eft == deny))

这一条规则意为在匹配结果中只要不存在deny的结果，那么最终结果就为allow。

e = some(where (p.eft == allow)) && !some(where (p.eft == deny))

这一条规则意味在匹配结果中，有一条为allow，且不存在deny的结果，那么最终结果就为allow。