casbin

介绍

https://casbin.org/

在Casbin，访问控制模型是基于PERM元模型 (Policy, Effect, Request, Matchers) 压缩而成的一个CONF文件。因此，项目授权机制的转换或升级就像修改配置一样简单。
Casbin已经支持了从MySQL、Postgres、Oracle到MongoDB、Redis、Cassandra、AWS S3等数十种数据库。请在此查看完整的支持列表：适配器.
Casbin已经使用Golang、Java、PHP和Node.js等等语言实现。所有的实现共享相同的 API 和行为。学习一次即可到处使用。

`casbin_rule`

casbin_rule是根据conf创建的表，不用的策略会对应不同的表

id：
- 这是一个唯一标识符，用于标识每一条策略规则。在许多数据库中，id 是一个自增的整数主键。
ptype：
- 代表策略类型（Policy Type）。常见的策略类型有：
  - p：基本策略规则（Policy Rule）。
  - g：角色继承关系（Role Definition）。
v0, v1, v2, v3, v4, v5：
- 这些列用于存储策略规则中的各个字段。具体含义取决于 ptype 的值。
- 对于策略类型 p，这些字段通常对应于主体（subject）、对象（object）、动作（action）等：
  - v0：主体（subject），如用户或角色。
  - v1：对象（object），如资源或资源路径。
  - v2：动作（action），如读取（read）或写入（write）。
  - v3-v5：可选字段，用于存储更多的策略信息，如果需要。
- 对于角色定义 g，这些字段通常用于定义角色关系：
  - v0：用户或子角色。
  - v1：父角色。

举例

[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) && r.obj == p.obj && r.act == p.act

使用数据库来存储策略，表 casbin_rule 的内容如下：

id	ptype	v0	v1	v2
1	p	admin	/data/*	read
2	p	admin	/data/*	write
3	p	user	/data/*	read
4	g	alice	admin
5	g	bob	user

关联和区别

作用对象不同：
- [request_definition] 描述的是实际运行时传递给 Casbin 的访问请求。
- [policy_definition] 描述的是策略存储中的权限规则。
定义内容不同：
- [request_definition] 定义了请求对象的组成部分，用于 enforce 方法来检查权限时的输入参数。
- [policy_definition] 定义了策略对象的组成部分，用于存储和解析权限规则。
使用场景不同：
- [request_definition] 在运行时使用，当你调用 enforce 方法时，Casbin 会根据这个定义解析传入的请求。
- [policy_definition] 在策略加载和解析时使用，当你加载策略文件或从数据库中读取策略时，Casbin 会根据这个定义解析策略规则。

pycasbin(python)

https://github.com/casbin/pycasbin

import casbin
from casbin_sqlalchemy_adapter import Adapter

# 自定义的 id_matcher 函数（如果需要）
def id_matcher(obj1, obj2):
    return obj1 == obj2

# 初始化 Casbin Enforcer
def get_enforcer():
    # Model 文件路径
    model_path = "auth_model.conf"
    
    # 初始化适配器（假设使用 SQLAlchemy 适配器）
    adapter = Adapter('sqlite:///casbin.db')  # 或其他数据库连接字符串
    
    # 初始化 Enforcer
    enforcer = casbin.Enforcer(model_path, adapter)
    
    # 添加自定义函数
    enforcer.add_function("id_matcher", id_matcher)
    
    return enforcer

# 示例：加载策略并执行权限判断
def check_permission():
    enforcer = get_enforcer()
    
    # 加载策略
    enforcer.load_policy()
    
    # 检查权限
    if enforcer.enforce('alice', '/data/resource1', 'read'):
        print("Access granted")
    else:
        print("Access denied")

    if enforcer.enforce('bob', '/data/resource1', 'write'):
        print("Access granted")
    else:
        print("Access denied")

if __name__ == "__main__":
    check_permission()

权限模式

RBAC

简介

基于角色的访问控制 (Role-based access control, RBAC) 是一种安全功能，用于控制用户访问那些通常仅限于超级用户访问的任务。通过对进程和用户应用安全属性，RBAC 可以在多个管理员之间划分超级用户的功能。进程权利管理通过权限实现。用户权利管理通过 RBAC 实现
RBAC实现了用户和权限点的分离，想对某个用户设置权限，只需要对该用户设置相应的角色即可，而该角色就拥有了对应的权限，这样一来，权限的分配和设计就做到了极简，高效，当想对用户收回权限时，只需要收回角色即可

https://blog.csdn.net/sinat_33087001/article/details/119842485

conf

[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) && keyMatch4(r.obj,p.obj) && r.act == p.act && id_matcher(p.obj,r.obj)

Casbin 的配置文件定义了访问控制模型，其中包括请求定义、策略定义、角色定义、策略效果和匹配器。在你提供的配置文件中，每个部分都有特定的功能和含义。下面逐一解释这些部分：

请求定义 (Request Definition)

[request_definition]

r = sub, obj, act

这一部分定义了访问请求的结构。请求包含三个元素：

- sub：主体（subject），即发起请求的用户或实体。

- obj：对象（object），即被访问的资源。

- act：动作（action），即对资源执行的操作（例如读、写）。

策略定义 (Policy Definition)

[policy_definition]

p = sub, obj, act

这一部分定义了策略的结构。策略包含三个元素：

- sub：主体（subject），即被授权的用户或实体。

- obj：对象（object），即被访问的资源。

- act：动作（action），即对资源执行的操作。

角色定义 (Role Definition)

[role_definition]

g = _, _

这一部分定义了角色的层级关系。角色定义的结构为：

- g：表示角色关系。一般情况下，第一个参数表示用户或角色，第二个参数表示其上级角色或群组。

例如，如果策略文件中有一行 g, alice, admin，这表示用户 alice 拥有 admin 角色的权限。

策略效果 (Policy Effect)

[policy_effect]

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

这一部分定义了策略效果的处理方式。`e` 表示策略效果，它的值为：

- some(where (p.eft == allow))：表示只要有一个策略的效果（`p.eft`）为 allow，则允许请求。

策略效果可以是 allow 或 deny，默认情况下，如果没有明确的 allow 策略，则请求会被拒绝。

匹配器 (Matchers)

[matchers]

m = g(r.sub, p.sub) && keyMatch4(r.obj,p.obj) && r.act == p.act && id_matcher(p.obj,r.obj)

匹配器定义了请求和策略之间的匹配规则。`m` 表示匹配规则，它的值为一个布尔表达式，用于判断请求是否与策略匹配：

- g(r.sub, p.sub)：检查请求中的主体 r.sub 是否属于策略中定义的角色 p.sub。`g` 是角色定义中的函数。

- keyMatch4(r.obj, p.obj)：检查请求中的对象 r.obj 是否与策略中的对象 p.obj 匹配。`keyMatch4` 是一个键匹配函数，用于匹配复杂的路径模式。

- r.act == p.act：检查请求中的动作 r.act 是否与策略中的动作 p.act 相同。

- id_matcher(p.obj, r.obj)：这是一个自定义的匹配函数，用于进一步检查对象的匹配情况。

例子

假设你有以下策略定义：

p, admin, /data/*, read

p, user, /data/*, write

g, alice, admin

g, bob, user

根据这个配置，`alice` 作为 admin 可以读取 /data/ 下的所有资源，而 bob 作为 user 可以写入 /data/ 下的所有资源。

当有一个请求 r = (alice, /data/resource1, read) 时：

1. g(r.sub, p.sub) 检查 alice 是否属于 admin，返回 true。

2. keyMatch4(r.obj, p.obj) 检查 /data/resource1 是否匹配 /data/*，返回 true。

3. r.act == p.act 检查 read 是否等于 read，返回 true。

4. id_matcher(p.obj, r.obj) 进一步检查对象的匹配情况，假设返回 true。

如果所有条件都满足，则该请求将被允许。

通过上述解释，你可以看到 Casbin 通过配置文件的模型定义，实现了灵活且强大的访问控制机制。

目录CONTENT

权限管理