Casbin学习笔记

基础知识

相关概念介绍

1. casbin相关概念

   1. casbin是一个开源的访问控制框架，支持多种访问控制模型，例如ACL，RBAC，ABAC

   2. casbin将支持的模型抽象出一种perm访问控制模型

   3. casbin有两个核心概念，model和policy

   4. casbin只支持访问控制，不支持用户身份认证和管理用户和角色列表

2. model概念

   1. model，即访问控制模型，需要在model中定义访问控制的模型，一般要对perm中的（策略、效果、请求、匹配）进行相关的定义，采用RBAC模型时，还需要定义角色

      1. 

      2. 上图为RBAC模型的model定义，需要对perm定义，并且定义角色

3. perm概念

   1. perm指的是policy（策略）、effect（效果）、request（请求）、match（匹配）

   2. 大致的过程就是，来了个请求，然后通过自定义的策略对该请求进行匹配操作，匹配结束后，将效果返回，在进行后续操作

   3. 策略

      1. 策略的格式在model中进行定义

         1. 

   4. 请求

      1. 请求的格式在model中进行定义

      2. 

   5. 匹配

      1. 把请求和策略中的每一条策略按照匹配的要求进行判定，然后赋值eft（allow或者deny）

      2. eft关键字，如果在model定义policy时定义了eft关键字，可以在策略文件中在添加个eft字段，默认是allow，也可以选择deny，当匹配中了的时候eft字段就会是allow（默认）或者deny（自定义）两种之一

   6. 效果

      1. 效果就是真正返回的结果，有true和false两种，true表示允许，false表示禁止

      2. 效果的写法只有4种，参考Model语法 · Casbin

简单演示

1. ACL模型

   1. 

   2. 对于该ACL示例中，model中定义了perm模型最简单的形式来实现ACL模型，对于第一个请求无法在策略中找到一条符合匹配规则的策略，所以返回的效果就是false，后两条请求均能找到，所以返回true

2. rbac模型

   1. 

   2. 对于该rabc示例中，在model文件中多了对角色的定义，策略文件中也多了一个关于用户和角色之间的对应关系。对于一个请求中的用户，首先会查寻策略，看他是什么角色，然后在以他拥有的角色和他原来的用户来查询策略，看是否匹配。

   3. 对于第一个请求，{alice, data2, read}，首先会发现alice有个角色叫data2_admin，然后会在所有的策略中进行匹配{alice, data2, read}和{data2_admin, data2, read}，其中之一匹配成功即可。第二个和第三个请求同理

3. abac模型

   1. 

   2. 基于属性的访问控制，可以可以使用主体、客体或动作的属性，而不是字符串本身来控制访问。casbin中用结构体来设置属性这个概念。对于示例中，匹配规则是，只有资源的主人这个属性是请求中的用户时才表示匹配上了，所以对于第一个请求来说是true，第二个是false

4. 混合模型实现

   1. 

1. 对于该模型中，混合了rbac和abac两种模型，

   1. 对于第一条请求，首次会根据策略查询具有的角色，发现有data1_admin这个角色，然后在判断该请求的用户是否是该资源的拥有者，也就是对属性进行匹配，然后就是对操作和资源的匹配

   2. 第二条请求，在角色匹配时会失败

   3. 第三条请求，在属性匹配时会失败

model函数

1. 在model中定义匹配规则时，可以使用函数，函数有内置函数和自定义函数

2. 内置函数函数 · Casbin

3. 自定义函数

   1. 

   2. 按照文档提示格式定义函数

   3. 

   4. 通过AddFunction 添加自定义函数。

   5. 添加后可以在model中的匹配操作进行使用

   6. 

存储

1. model存储

   1. model 只能加载，不能保存

   2. 有三种等效的方法来静态或动态地加载模型

      1. 从 .CONF 文件中加载 model，即将对模型的定义写在一个.CONF文件中

      2. 从代码加载 model，即将对模型的定义写在代码中，动态的加载

      3. 从字符串加载的 model，从多行字符串加载整个模型文本

2. policy存储

   1. 在Casbin中，策略存储作为adapter(Casbin的中间件) 实现。 Casbin用户可以使用adapter从存储中加载策略规则 (aka LoadPolicy()) 或者将策略规则保存到其中 (aka SavePolicy())

   2. 一般将policy保存在数据库中

适配器

通过适配器Gorm Adapter和API，将policy保存到MySQL数据库中

1. 先根据https://github.com/casbin/gorm-adapter拉取依赖

2. 刚开始数据库中没有相应的策略表

3. 

4. 运行代码会显示不通过，因为数据库中没有相应的策略

5. 

6. 第一次运行，会自动创建一个叫casbin的数据库，并且创建一个casbin_rule的策略表

7. 

8. 通过AddPolicy()向数据库中添加策略，并再次运行

9. 

10. 显示添加成功，并且匹配成功

11. 数据库中相应的策略表中也会有加入的策略

12. 

API

上面演示了添加的api，也有其他的增删改查的api，可以通过官方文档查看用法管理 API · Casbin

观察者

1. 支持使用分布式消息系统

2. 用户可以同时使用多个Casbin 执行器来处理大量的权限检查请求。

3. 不在主库中

4. 观察者 · Casbin

性能与优化

当应用于数以百万计的用户或权限的生产环境时，您可能会在Casbin 的强制执行中遇到性能降级

原因有两个：

1. 高访问量，每秒到来的请求数量过于庞大。

   1. 有两种方案解决

      1. 多线程运行多个casbin实例，参考多线程

      2. 将casbin实例部署到机器集群，参考观察者

      3. 当然也可以两者一起进行，部署到多个机器且每个机器多线程运行多个casbin实例

2. 策略规则过多

   1. 在云或多租户环境中，可能需要数百万条策略规则，导致加载策略规则速度很慢。

   2. 有几种解决策略

      1. 设计更加巧妙的Casbin模型或规则

      2. 通过共享让Casbin 的执行者只需要加载一套小套策略规则，例如：enforcer_0 只为tenant_0 到tenant_99提供服务, enforcer_1 只为tenant_100到tenant_199提供服务，参考策略子集加载

      3. 以授予RBAC角色权限，取代直接授予用户权限。