Casbin访问控制框架入门详解及Java案例示范

Casbin 开源访问控制框架强大高效，其权限管理机制支持多种访问控制模型。

Casbin 可以：

使用casbin，在前端和后端分离中，前端每次只传输一个用户JWT，后端就知道当前访问了API是否有权限。Casbin支持多语言，以便在不改变策略的情况下使用其他语言。

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。

Model是Casbin具体访问模型主要以文件的形式出现，通常以文件的形式出现.conf最为后缀。

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

[request_definition] r = sub, obj, act 

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

[policy_definition] p = sub, obj, act 

[policy_definition] 部分是对policy的定义，policy每一行的一部分都被称为策略规则， 每一条战略规则通常都是形成的p, p2的policy type开头。

[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 

上述匹配器是最简单的，这意味着要求中的主题、对象和行动应与政策规则相匹配。

# 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 

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

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

• 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 只是将其识别为一个字符串。

run the test，结果为true。这是因为alice, domain1, data1, write 首先通过g(r.sub, p.sub, r.dom)映射成admin, domain1, data1, write，然后再去Policy中去进行查找，发现可以找到这条规则，因此返回为true。

 <dependencies>
        <dependency>
            <groupId>org.casbingroupId>
            <artifactId>jcasbinartifactId>
            <version>1.2.0version>
        dependency>
 dependencies>

[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, zhangsan, data1, read

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("未通过");
        }
    }
}