【项目开发Trip第2站】casbin库与身份权限划分
casbin库与身份权限划分
一、 Casbin 是什么？
Casbin 是一个强大高效的 开源访问控制库，支持多种访问控制模型（如 ACL, RBAC, ABAC 等）。它不是一个完整的身份认证或用户管理框架，而是专门负责处理 授权 问题，即回答“谁可以对什么进行什么操作？”。
核心思想：将授权逻辑与业务代码分离。你可以通过一个配置文件（模型文件）来定义你的安全策略，从而轻松调整授权规则，而无需重写大量代码。
二、 核心基础：PERM 元模型
Casbin 的核心是一个名为 PERM 的元模型（Policy, Effect, Request, Matchers）。几乎所有访问控制模型都可以通过这个元模型来定义。
PERM 模型包含四个核心部分：
-
请求 (Request):
- 定义了一个访问请求的标准参数。通常是一个元组（三元组或四元组）。
- 标准形式是：
sub, obj, act。sub: 访问的主体（例如：用户alice，角色admin）obj: 访问的资源（例如：数据data1，页面/api/user）act: 执行的操作（例如：read，write，delete）
-
策略 (Policy):
- 定义了具体的授权规则，也就是访问控制策略的实际内容。它和 Request 的形式是对应的。
- 通常也以
sub, obj, act的形式存储在策略文件中或数据库里。例如一条策略p, alice, data1, read表示 “alice 可以读取 data1”。 - 你提到的
p和g就在这里定义（详见第四部分）。
-
匹配器 (Matchers):
- 这是授权逻辑的核心。它是一个表达式，用于将 请求 (Request) 与已定义的 策略 (Policy) 进行匹配。
- 例如：
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act - 这个匹配器的意思是：如果请求的
sub,obj,act分别与某条策略的sub,obj,act完全一致，则这条策略匹配成功。
-
效果 (Effect):
- 当匹配器找到多条匹配的策略时，Effect 根据这些策略的结果（
allow或deny）来决定最终的授权结果。 - 最常见的 Effect 是：
e = some(where (p.eft == allow))- 这意味着只要有一条匹配的策略结果是
allow，最终结果就是允许。
- 这意味着只要有一条匹配的策略结果是
- 你也可以定义更复杂的策略，如拒绝覆盖（deny-override）：
e = some(where (p.eft == allow)) && !some(where (p.eft == deny))
- 当匹配器找到多条匹配的策略时，Effect 根据这些策略的结果（
- 两个情况下的使用案例
1. 成功案例
场景描述
用户VIP等级为1，请求使用deepseek-v3.1模型
执行流程分析
-
请求生成
- 程序创建授权请求：
(1, "deepseek-v3.1", "use") - 对应格式：
(sub=VIP等级, obj=模型名称, act=操作)
- 程序创建授权请求：
-
策略匹配
- 在策略文件中查找匹配规则
- 找到对应策略：
p, 1, deepseek-v3.1, use - 三元组完全匹配：VIP等级、模型名称、操作类型一致
-
效果评估
- 应用Effect规则：
e = some(where (p.eft == allow)) - 存在allow策略 → 授权通过
- 应用Effect规则：
-
程序优化
- 代码中使用了
break语句，匹配成功后立即终止循环 - 避免不必要的后续权限检查，提升性能
- 代码中使用了
权限规则验证
VIP权限等级：
- VIP0 → doubao-seed-1.6-vision
- VIP1 → deepseek-v3.1 ✓ (当前用户)
- VIP2 → kimi-k2
2. 失败
场景描述
用户VIP等级为0，请求使用kimi-k2模型
执行流程分析
-
请求生成
- 授权请求：
(0, "kimi-k2", "use") - 用户VIP等级0尝试访问需要VIP2权限的模型
- 授权请求：
-
策略匹配过程
- 检查策略1：
p, 0, doubao-seed-1.6-vision, use→ 模型不匹配 - 检查策略2：
p, 1, deepseek-v3.1, use→ VIP等级不匹配 - 检查策略3：
p, 2, kimi-k2, use→ VIP等级不匹配
- 检查策略1：
-
授权决策
- 无任何策略匹配成功
- Effect规则要求至少存在一个allow策略
- 最终结果：拒绝访问
权限规则验证
用户权限现状：
- 当前用户：VIP0
- 允许访问：doubao-seed-1.6-vision
- 尝试访问：kimi-k2 (需要VIP2)
- 权限差距：2个等级
三、 模型文件 (model.conf) 和策略文件 (policy.csv)
Casbin 的使用通常涉及两个配置文件：
- 模型文件 (
model.conf)： 定义你的授权模型。它使用 PERM 元模型来声明 Request、Policy、Matcher 和 Effect。 - 策略文件 (
policy.csv) 或 数据库： 存储具体的策略规则。这是可以动态加载和修改的部分。
示例：
model.conf
[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
policy.csv
p, alice, data1, read
p, bob, data2, write
代码中检查授权：
// 伪代码
if enforcer.Enforce("alice", "data1", "read") == true {// 允许访问
} else {// 拒绝访问
}
// 这个调用会返回 true，因为策略中存在 p, alice, data1, read
四、 策略中的 p 和 g 是什么？
在模型文件的 [policy_definition] 部分，你可以定义两种类型的策略：
-
p(策略定义):- 用于定义普通的权限规则。格式为
p, sub, obj, act。 - 它直接描述了“谁能对什么做什么”。
- 示例：
p, admin, /api/user, GET表示角色为 admin 的主体可以 GET /api/user 这个资源。
- 用于定义普通的权限规则。格式为
-
g(角色定义):- 用于定义角色继承关系（RBAC 模型的核心）。格式为
g, sub, obj。 - 在标准 RBAC 中，它的含义是
g, user, role，表示“用户user具有角色role”。 - 它也支持角色继承，例如
g, role1, role2表示“角色role1继承角色role2的所有权限”。
- 用于定义角色继承关系（RBAC 模型的核心）。格式为
示例 (policy.csv)：
p, admin, data, write
p, developer, data, read
g, alice, admin # alice 拥有 admin 角色
g, bob, developer # bob 拥有 developer 角色
g, charlie, admin # charlie 也拥有 admin 角色
g, admin, developer # admin 角色继承 developer 角色（所以admin也能read）
在这个例子中，alice 由于是 admin，而 admin 继承了 developer，所以 alice 同时拥有 data, write 和 data, read 的权限。
五、 几种经典模型和应用场景
Casbin 通过不同的模型文件可以实现多种授权模型。
| 模型 | 描述 | 应用场景 | 模型文件关键点示例 |
|---|---|---|---|
| ACL（访问控制列表） | 直接为用户分配资源权限。简单直接。 | 简单的系统，用户量少，权限不复杂。如个人博客后台。 | m = r.sub == p.sub && r.obj == p.obj && r.act == p.act |
| RBAC（基于角色的访问控制） | 权限分配给角色，用户被赋予角色。最常用。 | 企业系统、SaaS 平台。用户和权限多，需要分层管理。如 CMS、ERP。 | 必须包含 g 定义，matcher 中需使用 g(r.sub, p.sub) 来检查角色。 |
| ABAC（基于属性的访问控制） | 根据主体、资源、环境的属性动态决策。非常灵活强大。 | 复杂且动态的授权需求。如：办公时间才可访问；用户只能访问自己创建的文件；费用超过阈值需经理审批。 | 在 Request 和 Matcher 中使用属性（如 r.sub, r.obj, r.act, r.env）。Matcher 类似函数：m = r.sub == r.obj.owner && r.env.hour >= 9 && r.env.hour <= 17 |
| Restful | RBAC 的一种特化，通常将 URL 路径和 HTTP 方法作为资源和操作。 | 现代 API 授权。如：GET /api/v1/users。 | 策略可能为 p, admin, /api/v1/users, GET，Matcher 可能支持路径匹配（如 KeyMatch）。 |
其中的Restful模型虽然是一种特殊化，听上去有点吓人，但是时间上就是将划分的内容改成了URL路径罢了，并没有高级到哪去
六、模型选择指南
根据项目规模选择
| 项目类型 | 推荐模型 | 选择理由 |
|---|---|---|
| 个人项目/原型 | ACL | 配置简单，快速上手 |
| 中小型企业应用 | RBAC | 角色管理清晰，维护性好 |
| 大型SaaS平台 | RBAC with 多租户 | 支持客户隔离，权限复用 |
| 高安全要求系统 | ABAC | 动态属性检查，细粒度控制 |
总结
| 特性 | 描述 |
|---|---|
| 核心价值 | 将授权逻辑与业务代码解耦，提供统一的授权接口。 |
| 核心模型 | PERM 元模型（Request, Policy, Matcher, Effect）。 |
| 关键文件 | 模型文件（model.conf）定义“如何判断”，策略文件（policy.csv/DB）定义“具体规则”。 |
| 关键策略 | p 定义权限，g 定义角色和继承关系（RBAC 核心）。 |
| 支持模型 | ACL, RBAC, ABAC, Restful 等，高度灵活可配置。 |
| 语言支持 | Go, Java, Node.js, Python, C++, .NET 等十几种语言。 |