侧边栏壁纸
  • 累计撰写 94 篇文章
  • 累计创建 35 个标签
  • 累计收到 1 条评论

目 录CONTENT

文章目录

Casbin-开源多语言访问控制框架-核心介绍

天明
2023-11-12 / 0 评论 / 0 点赞 / 61 阅读 / 5613 字 / 正在检测是否收录...

Casbin是一个强大的、高效的开源访问控制框架,其权限管理机制支持多种访问控制模型。
它有两个配置文件,model.conf 和 policy.csv。其中 model.conf 存储的是我们的访问控制模型,policy.csv 存储的是我们具体的用户权限配置。
注意model.conf 一旦修改,对应的 policy 就需要进行同步修改,所以 model 在一个系统中不要进行频繁修改。

PML(PERM modeling language)。其中的 PERM 指的是 Policy-Effect-Request-Matcher

Request 请求

它的写法是
request ::= r : attributes attributes ::= {attr1, attr2, attr3, ..}
比如我们写一行:
r = sub, obj, act
代表一个请求有三个标准的元素,请求主体,请求对象,请求操作。其中的sub, obj, act 可以是自己定义的,只要你在一个配置文件中定义的元素标识符一致就行。

Policy - 规则(策略),它表示具体的权限定义的规则是什么。

它同样是形如 p = sub, obj, act 的表示方法,比如我们定义了 policy 的规则如此,那么我们在 policy.csv 中每一行定义的 policy_rule 就必须和这个属性一一对应。

Policy_Rule

在 policy.csv 文件中定义的策略就是 policy_rule。它和 Policy 是一一对应的。
比如 policy 为
p = sub , obj , act
设置的一条 policy_rule 为
p , bob , data2 , write
表示 bob(p.sub = bob)可以对 data2 (p.obj = data2) 进行 write (p.act = write) 操作这个规则。
policy 默认的最后一个属性为决策结果,字段名 eft,默认值为 allow,即通过情况下,p.eft 就设置为 allow。

Matcher - 判断

有请求,有规则,那么请求是否匹配某个规则,则是 matcher 进行判断的。

matcher ::= (variables, constants, stub functions) variables ::= {r.attr1, r.attr2, .., p.attr1, p.attr2, ..} constants ::= {const1, const2, const3, ..}
比如下面这个 matcher :
m = r . sub == p . sub && r . obj == p . obj && r . act == p . act
表示当(r.sub == p.sub && r.obj == p.obj && r.act == p.act )的时候,返回 true,否则返回 false。

Effect

Effect 用来判断如果一个请求满足了规则,是否需要同意请求。它的规则比较复杂一些。
例子:
e = some ( where ( p . eft == allow ))
这句话的意思就是将 request 和所有 policy 比对完之后,所有 policy 的策略结果(p.eft)为 allow 的个数 >=1,整个请求的策略就是为 true。

自定义函数

自定义函数是在 matcher 中使用的。我们可以自己定义一个函数,然后注册进 enforcer,在 matcher 中我们就可以使用了。

image.png

1、我们先定义属性,通用的一些属性如 subject, object, action。
2、定义的属性可以作为 Request 的属性,也可以作为 Policy 的属性。
3、Policy_Rule 是 Policy 的具体规则。
4、使用定义的 Matcher 将 Request 和 Policy 进行匹配,这个匹配的过程可能使用到自定义函数。
5、所有的 Policy 匹配完成的结果,通过 Effect 规则得出最终是否可以访问的结果。

Casbin 支持的权限模型有

ACL (Access Control List, 访问控制列表)
具有超级用户的ACL
没有用户的 ACL: 对于没有身份验证或用户登录的系统尤其有用。
没有资源的 ACL: 某些场景可能只针对资源的类型, 而不是单个资源, 诸如 write-article, read-log等权限。它不控制对特定文章或日志的访问。
RBAC (基于角色的访问控制)
支持资源角色的RBAC: 用户和资源可以同时具有角色 (或组)。
支持域/租户的RBAC: 用户可以为不同的域/租户设置不同的角色集。
ABAC (基于属性的访问控制): 支持利用resource.Owner这种语法糖获取元素的属性。
RESTful: 支持路径, 如 /res/*, /res/: id 和 HTTP 方法, 如 GET, POST, PUT, DELETE。
拒绝优先: 支持允许和拒绝授权, 拒绝优先于允许。
优先级: 策略规则按照先后次序确定优先级,类似于防火墙规则。

访问控制模型

UGO(User, Group, Other)

这个是Linux中对于资源进行权限管理的访问模型。Linux中一切资源都是文件,每个文件都可以设置三种角色的访问权限(文件创建者,文件创建者所在组,其他人)。
缺点:只能为一类用户设置权限,如果这类用户中有特殊的人,那么它无能为力了。

ACL(访问控制列表)

它的原理是,每个资源都配置有一个列表,这个列表记录哪些用户可以对这项资源进行CRUD操作。当系统试图访问这项资源的时候,会首先检查这个列表中是否有关于当前用户的访问权限,从而确定这个用户是否有权限访问当前资源。

RBAC(基于角色的权限访问控制)

这个是很多业务系统最通用的权限访问控制系统。它的特点是在用户和具体权限之间增加了一个角色。就是先设置一个角色,比如管理员,然后将用户关联某个角色中,再将角色设置某个权限。用户和角色是多对多关系,角色和权限是多对多关系。所以一个用户是否有某个权限,根据用户属于哪些角色,再根据角色是否拥有某个权限来判断这个用户是否有某个权限。

RBAC的逻辑有更多的变种。

变种一:角色引入继承

角色引入了继承概念,那么继承的角色有了上下级或者等级关系。

变种二:角色引入了约束

角色引入了约束概念。约束概念有两种,

一种是静态职责分离:
a、互斥角色:同一个用户在两个互斥角色中只能选择一个
b、基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的
c、先决条件约束:用户想要获得高级角色,首先必须拥有低级角色

一种是动态职责分离:可以动态的约束用户拥有的角色,如一个用户可以拥有两个角色,但是运行时只能激活一个角色。

变种三:既有角色约束,又有角色继承

就是前面两种角色变种的集合。

ABAC(基于属性的权限验证)

Attribute-based access control,这种权限验证模式是用属性来标记资源权限的。比如k8s中就用到这个权限验证方法。
这个权限验证模型的好处就是扩展性好,一旦要增加某种权限,就可以直接增加某种属性。

DAC(自主访问控制)

在ACL的访问控制模式下,有个问题,能给资源增加访问控制的是谁,这里就有几种办法,比如增加一个super user,这个超级管理员来做统一的操作。还有一种办法,有某个权限的用户来负责给其他用户分配权限。这个就叫做自主访问控制。

MAC(强制访问控制)

强制访问控制和DAC相反,它不将某些权限下放给用户,而是在更高维度(比如操作系统)上将所有的用户设置某些策略,这些策略是需要所有用户强制执行的。这种访问控制也是基于某些安全因素考虑。

0

评论区