其他|Casbin访问控制框架入门详解及Java案例示范 casbin|访问控制框架|java

1、Casbin基本介绍 Casbin 是一个强大的、高效的开源访问控制框架，其权限管理机制支持多种访问控制模型。

文章图片

Casbin 可以：

支持自定义请求的格式，
List item

默认的请求格式为{subject, object, action}。
2. 具有访问控制模型model和策略policy两个核心概念。
3. 支持RBAC中的多层角色继承，不止主体可以有角色，资源也可以具有角色。
4. 支持内置的超级用户例如：root 或 administrator。超级用户可以执行任何操作而无需显式的权限声明。
5. 支持多种内置的操作符，如 keyMatch，方便对路径式的资源进行管理，如 /foo/bar 可以映射到 /foo*
2、为什么要使用Casbin 使用casbin，在前后端分离中，前端每次只要传一个包含用户的JWT，后端就知道当前访问的API是否有权限。另外，Casbin支持多语言，这样在策略不用改变的情况下，别的语言也可以使用。
3、工作原理 PERM模型
在 Casbin 中, 访问控制模型被抽象为基于 PERM (Policy, Effect, Request, Matcher) 的一个文件，描述了资源与用户之间的关系。
PERM ：

Policy：策略，定义权限的规则， p = {sub, obj, act, eft}，策略一般存储到数据库，因为会有很多。
Effect：影响，它决定我们是否可以放行。
Request: 访问请求, r = {sub, obj, act}。
Matcher: 匹配规则，判断 Request 是否满足 Policy。

Request
一个请求可能长这样： r={sub,obj,act}，它实际上定义了我们应该提供访问控制匹配功能的参数名称和顺序。
sub, obj, act, eft含义如下：

sub：subject，访问实体；
obj： object，访问的资源；
act： action，访问方法；
eft： effect，策略结果，一般为空，默认指定allow，还可以定义为deny。

4、Module File 语法 Model是Casbin的具体访问模型，其主要以文件的形式出现，该文件常常以.conf最为后缀。

Model CONF 至少应包含四个部分: [request_definition], [policy_definition], [policy_effect], [matchers]。
如果 model 使用 RBAC, 还需要添加[role_definition]部分。
Model CONF 文件可以包含注释。注释以 # 开头， # 会注释该行剩余部分。

Request定义

[request_definition] r = sub, obj, act

[request_definition] 部分用于request的定义，它明确了 e.Enforce(…) 函数中参数的含义。sub, obj, act 表示经典三元组: 访问实体 (Subject)，访问资源 (Object) 和访问方法 (Action)。
Policy定义

[policy_definition] p = sub, obj, act

[policy_definition] 部分是对policy的定义，policy部分的每一行称之为一个策略规则，每条策略规则通常以形如p, p2的policy type开头。
Policy effect定义

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

[policy_definition] 部分是对policy的定义。上面的策略效果表示如果有任何匹配的策略规则允许, 最终效果是允许 (aka allow-override). p.eft 是策略的效果，它可以允许或否定。它是可选的，默认值是允许。因为我们没有在上面指定它，所以它使用默认值。
匹配器
[matchers] 是策略匹配程序的定义。匹配程序是表达式。它定义了如何根据请求评估策略规则。

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

上述匹配器是最简单的，这意味着请求中的主题、对象和行动应该与政策规则中的匹配。
完整model.conf

# Request定义 [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

5、Casbin模型 ACL模型
我们定义一个策略 p = {sub, obj, act}，定义一个匹配规则，通过请求过来的参数 r = {sub, obj, act}与策略通过规则进行匹配，获得一个Effect影响，拿到影响的结果，进入影响的表达式，返回一个布尔值。

文章图片

run the test，我们可以发现第一行，第二行为true，第三行为false。这是因为在Policy中，我们定义了用户名为alice的这个人有对data1，data2数据的read和write的操作，因此查询结果返回为true。而没有定义其对data2的read操作，因此返回为false。
RBAC模型

g = _ , _ 表示用户是哪个角色；
g = ,,_ 表示用户是哪个角色，属于哪个商户。

文章图片

run the test，我们可以发现第一行，第二行都为true。这是因为alice, data2, read首先通过g(r.sub, p.sub)映射成data2_admin, data2, read，然后data2_admin, data2, read在Policy中去进行查找，发现可以找到这条规则，因此返回为true。这意味着 alice 是角色 data2_admin的一个成员。alice 在这里可以是用户、资源或角色。 Cabin 只是将其识别为一个字符串。
RABC with domains/tenants

文章图片

run the test，结果为true。这是因为alice, domain1, data1, write 首先通过g(r.sub, p.sub, r.dom)映射成admin, domain1, data1, write，然后再去Policy中去进行查找，发现可以找到这条规则，因此返回为true。
6、Java代码实践（Casbin小案例） 6.1、项目结构

文章图片
6.2、引入依赖

org.casbin jcasbin 1.2.0

6.3、引入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

6.4、引入policy.csv文件
policy.csv文件就相当于一张权限表。

p, zhangsan, data1, read

6.5、引入核心测试代码

import org.casbin.jcasbin.main.Enforcer; public class MyMain { public static void main(String[] args) { String resPath = MyMain.class.getResource("/").getPath(); Enforcer e = new Enforcer(resPath + "model.conf", resPath + "policy.csv"); String sub = "zhangsan"; String obj = "data1"; String act = "read"; if (e.enforce(sub, obj, act) == true) { System.out.println("通过"); } else { System.out.println("未通过"); } } }

6.5、运行结果
【其他|Casbin访问控制框架入门详解及Java案例示范】