Golang最强大的访问控制框架casbin全解析
2020-01-16 11:09 轩脉刃 阅读(27699) 评论(3) 编辑 收藏 举报Golang最强大的访问控制框架casbin全解析
Casbin是一个强大的、高效的开源访问控制框架,其权限管理机制支持多种访问控制模型。目前这个框架的生态已经发展的越来越好了。提供了各种语言的类库,自定义的权限模型语言,以及模型编辑器。在各种语言中,golang的支持还是最全的,所以我们就研究casbin的golang实现。
访问控制模型
控制访问模型有哪几种?我们需要先来了解下这个。
UGO(User, Group, Other)
这个是Linux中对于资源进行权限管理的访问模型。Linux中一切资源都是文件,每个文件都可以设置三种角色的访问权限(文件创建者,文件创建者所在组,其他人)。这种访问模型的缺点很明显,只能为一类用户设置权限,如果这类用户中有特殊的人,那么它无能为力了。
ACL(访问控制列表)
它的原理是,每个资源都配置有一个列表,这个列表记录哪些用户可以对这项资源进行CRUD操作。当系统试图访问这项资源的时候,会首先检查这个列表中是否有关于当前用户的访问权限,从而确定这个用户是否有权限访问当前资源。linux在UGO之外,也增加了这个功能。
setfacl -m user:yejianfeng:rw- ./test
[yejianfeng@ipd-itstool ~]$ getfacl test
# file: test
# owner: yejianfeng
# group: yejianfeng
user::rw-
user:yejianfeng:rw-
group::rw-
mask::rw-
other::r--
当我们使用getfacl和setfacl命令的时候我们就能对某个资源设置增加某个人,某个组的权限列表。操作系统会根据这个权限列表进行判断,当前用户是否有权限操作这个资源。
RBAC(基于角色的权限访问控制)
这个是很多业务系统最通用的权限访问控制系统。它的特点是在用户和具体权限之间增加了一个角色。就是先设置一个角色,比如管理员,然后将用户关联某个角色中,再将角色设置某个权限。用户和角色是多对多关系,角色和权限是多对多关系。所以一个用户是否有某个权限,根据用户属于哪些角色,再根据角色是否拥有某个权限来判断这个用户是否有某个权限。
RBAC的逻辑有更多的变种。
变种一:角色引入继承
角色引入了继承概念,那么继承的角色有了上下级或者等级关系。
变种二:角色引入了约束
角色引入了约束概念。约束概念有两种,
一种是静态职责分离:
a、互斥角色:同一个用户在两个互斥角色中只能选择一个
b、基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的
c、先决条件约束:用户想要获得高级角色,首先必须拥有低级角色
一种是动态职责分离:
可以动态的约束用户拥有的角色,如一个用户可以拥有两个角色,但是运行时只能激活一个角色。
变种三:既有角色约束,又有角色继承
就是前面两种角色变种的集合。
ABAC(基于属性的权限验证)
Attribute-based access control,这种权限验证模式是用属性来标记资源权限的。比如k8s中就用到这个权限验证方法。比如某个资源有pod属性,有命名空间属性,那么我设置的时候可以这样设置:
Bob 可以在命名空间 projectCaribou 中读取 pod:
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
这个权限验证模型的好处就是扩展性好,一旦要增加某种权限,就可以直接增加某种属性。
DAC(自主访问控制)
在ACL的访问控制模式下,有个问题,能给资源增加访问控制的是谁,这里就有几种办法,比如增加一个super user,这个超级管理员来做统一的操作。还有一种办法,有某个权限的用户来负责给其他用户分配权限。这个就叫做自主访问控制。
比如我们常用的windows就是用这么一种方法。
很多的wiki权限也是这样的权限管理方式。
MAC(强制访问控制)
强制访问控制和DAC相反,它不将某些权限下放给用户,而是在更高维度(比如操作系统)上将所有的用户设置某些策略,这些策略是需要所有用户强制执行的。这种访问控制也是基于某些安全因素考虑。
casbin的基本使用
casbin使用配置文件来设置访问控制模型。我们可以通过casbin的模型编辑器来查看。
它有两个配置文件,model.conf 和 policy.csv。其中 model.conf 存储的是我们的访问控制模型,policy.csv 存储的是我们具体的用户权限配置。
权限本质上就是最终询问这么一个问题“某个用户,对某个资源,是否可以进行某种操作”。casbin的使用非常精炼。基本上就生成一个结构,Enforcer,构造这个结构的时候加载 model.conf 和 policy.csv。使用示例如下:
import "github.com/casbin/casbin/v2"
e, err := casbin.NewEnforcer("path/to/model.conf", "path/to/policy.csv")
sub := "alice" // the user that wants to access a resource.
obj := "data1" // the resource that is going to be accessed.
act := "read" // the operation that the user performs on the resource.
ok, err := e.Enforce(sub, obj, act) // 查看alice是否对data1z这个资源有read权限
if err != nil {
// handle err
}
if ok == true {
// permit alice to read data1
} else {
// deny the request, show an error
}
当然,casbin 可以读取具体 policy 的时候不仅仅可以通过 csv 文件进行读取,也可以通过数据库进行读取。这样我们甚至可以写一个用户管理后台来配置不同的用户权限。model.conf 也是可以从配置文件中获取,也可以从代码中获取,从代码中获取就可以扩展为先读取数据库,再代码加载。但是 model.conf 一旦修改,对应的 policy 就需要进行同步修改,所以 model 在一个系统中不要进行频繁修改。
PML
casbin 是一种典型的“配置即一切”的软件思路,那么它的配置语法就显得格外重要。我们可以通过 casbin 的在线配置编辑器 https://casbin.org/en/editor 来进行学习。
casbin 的理论基础是这么一篇论文:PML:一种基于Interpreter的Web服务访问控制策略语言 。这篇论文是北大的三个学生一起发表的。要理解 casbin 的配置文件,就需要先看这篇论文。
论文的作者觉得现在云计算时代,权限管理系统是各种云非常重要的组成部分,但是各种权限管理模型在各个云厂商,或者各种云时代的产品又都不一样。那么是否有一种权限模型来统一描述各种权限访问方式呢?如果有的化,这种权限模型又需要独立于各种语言而存在,才能被各种语言的云产品所通用。
于是论文就创造除了这么一种语言:PML(PERM modeling language)。其中的 PERM 指的是 Policy-Effect-Request-Matcher 。 下面我们需要一一了解每一个概念。
Request
Request 代表的是请求,它的写法是
request ::= r : attributes
attributes ::= {attr1, attr2, attr3, ..}
比如我们写一行:
r = sub, obj, act
代表一个请求有三个标准的元素,请求主体,请求对象,请求操作。其中的sub, obj, act 可以是自己定义的,只要你在一个配置文件中定义的元素标识符一致就行。
Policy
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 ::=< boolean expr > (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 用来判断如果一个请求满足了规则,是否需要同意请求。它的规则比较复杂一些。
effect ::=< boolean expr > (effect term1, effect term2, ..)
effect term ::= quantifier, condition
quantif ier ::= some|any|max|min
condition ::=< expr > (variables, constants, stub functions)
variables ::= {r.attr1, r.attr2, .., p.attr1, p.attr2, ..}
constants ::= {const1, const2, const3, ..}
这里的 quantifier一般是some(论文中支持max和min),some表示括号中的表达式个数大于等于1就行。max/min表示括号中表达式的结果取最大/小的。(这里我不是很理解,不过好像casbin也没有实现min和max)
下面这个例子:
e = some(where (p.eft == allow))
这句话的意思就是将 request 和所有 policy 比对完之后,所有 policy 的策略结果(p.eft)为allow的个数 >=1,整个请求的策略就是为 true。
自定义函数
自定义函数是在 matcher 中使用的。我们可以自己定义一个函数,然后注册进enforcer,在matcher中我们就可以使用了。
比如
func KeyMatch(key1 string, key2 string) bool {
i := strings.Index(key2, "*")
if i == -1 {
return key1 == key2
}
if len(key1) > i {
return key1[:i] == key2[:i]
}
return key1 == key2[:i]
}
func KeyMatchFunc(args ...interface{}) (interface{}, error) {
name1 := args[0].(string)
name2 := args[1].(string)
return (bool)(KeyMatch(name1, name2)), nil
}
e.AddFunction("my_func", KeyMatchFunc)
// 配置文件中就可以这样写了
[matchers]
m = r.sub == p.sub && my_func(r.obj, p.obj) && r.act == p.act
casbin中有一些自定义的函数:
关系
上面几个概念关系如下:
大概解释一下:
1 我们先定义属性,通用的一些属性如 subject, object, action。
2 定义的属性可以作为 Request 的属性,也可以作为 Policy的属性。
3 Policy_Rule 是 Policy 的具体规则。
4 使用定义的 Matcher 将 Request 和 Policy 进行匹配,这个匹配的过程可能使用到自定义函数。
5 所有的 Policy 匹配完成的结果,通过 Effect 规则得出最终是否可以访问的结果。
例子:ACL
理解上面的知识,我们应该能理解这个ACL的例子:
这个例子中定义了两个 Policy_Rule: (alice 对 data1 有 read 权限) 和 (bob 对 data2 有 write 权限)
当request (alice, data1, read)进来的时候,它匹配了其中一条规则,所以some 之后的最终结果为true。
例子:RESTFUL
RESTFUL接口使用URL和HTTP请求方法表示资源的增删改查,那么我们可以使用自定义函数来判断是否可以进行某个请求
更多
这个论文还有一些其他的定义:
Has_Role
其实这个就是一个自定义函数的概念,只是它的参数是请求的主体和角色。这里引入了一个角色的概念。这个也是RBAC 权限模型所定义的。Has_Role 本质就是定义了一个 g 函数,这个 g 用于判断哪个用户是否属于哪个角色。这个 g 的函数也可以用配置写规则:
g = _, _
然后在 Policy 写规则:
g, alice, data2_admin
表示 alice 属于角色 data2_admin。
matcher 就可以写成这样:
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
例子:RBAC
我们来看下下面这个RBAC的规则:
我们可以看这里的 Policy 中,其实用户和角色是分不出来的,(比如我们单看policy里面的p,是不了解data2_admin是用户,还是角色的)。但是我们有一个 g (has_role)的规则,说明了alice 是有 data2_admin的角色的。
那么最终判断请求, alice, data2, read, 由于alice 有data2_admin的角色,它满足了(p, data2_admin, data2, read) 这条规则,所以最终判定结果为 true。
其实有了这个has_role,我们也可以把一个用户属于另一个用户的关系做出来。这个也就是 RBAC1 的。
Has Tenant Role
g 函数同时也可以有三个参数,两个参数的时候表示“谁 是 什么角色”,三个参数的时候表示“谁 在 什么域 是 什么角色”。
这个还是直接看例子:
在这个例子里面,有个域的概念,它就相当于可以表示“某个用户在某个域(租户)中是什么角色”。
这个是实现了一种基于RBAC的分权分域用户权限系统。
总结
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。
- 拒绝优先: 支持允许和拒绝授权, 拒绝优先于允许。
- 优先级: 策略规则按照先后次序确定优先级,类似于防火墙规则。
我们可以通过这个页面上的链接看每个权限模型的配置:https://casbin.org/docs/zh-CN/supported-models
源码阅读
我们阅读的是 v2.1.2版本
源码地址:https://github.com/casbin/casbin 。
注释版地址:https://github.com/jianfengye/inside-go/tree/master/casbin-2.1.2。
按照大象装进冰箱的逻辑,我们也很容易想象得到 casbin 应该分为几个步骤:
1 加载 model 的配置
2 加载 policy 的配置
3 具体请求进来之后,和 model 和 policy 进行匹配判断。
确实源码也就是这么写的。
整个 casbin 最核心的结构是
// Enforcer是权限验证的主体
type Enforcer struct {
modelPath string // model文件地址
model model.Model // model结构
fm model.FunctionMap // 自定义函数
eft effect.Effector // effecter的逻辑
adapter persist.Adapter // 持久化的Adapter,就是police的Adapter
watcher persist.Watcher
rm rbac.RoleManager // 这个要是这个模型是rbac(根据是否有g判断),就增加这个角色管理器
enabled bool // 这个Enforcer的开关
autoSave bool // 如果调用了api修改的Policy,是否自动保存到Adapter中
autoBuildRoleLinks bool
}
所有加载的 model 和 policy 都是丰富这个结构体。
比如:
func (e *Enforcer) LoadModel() error
或者
func (e *Enforcer) LoadPolicy() error
里面的逻辑就不细说了,可以去看 https://github.com/jianfengye/inside-go/tree/master/casbin-2.1.2 看这个的源码注释。我就说几个我觉得这个项目代码值得学习或者比较特别的点。
代码依赖少
这个项目的 config, log 都是自己从标准库从头开始写的。我认为,作者一开始对项目就定位很清晰,这个是一个基础类库,能依赖尽可能少的项目就依赖尽可能少的项目。
文件夹及文件定义很明确
casbin 的文件夹结构并不是扁平的,而是树形结构,基本上是两层,甚至用到了三层。我个人觉得一个小的类库倒是没有必要分割这么多文件夹,很容易让人感觉很复杂。不过在 casbin 这个项目中,文件夹分割的还是比较清晰的。基本上是顺着 enforcer 这个结构体的定义,在涉及到需要扩展的字段的时候就起一个文件夹。每个扩展的文件夹基本都是 interface + implement 的方式。比如 enforcer 中有个 adapter 字段,使用了persist文件夹进行接口的定义和实现。
文件的定义也很清晰。比如 enforcer_interface 定义了80多个接口,在一个文件中全部实现并不是很好的写法,它就分成了同一个文件夹下的几个文件来写(internal_api, rbac_api, management_api,rbac_api_with_domain)。这样不仅减少了代码的长度,还使用文件名称把接口进行了分类。
基于 enforcer 扩展了 CacheEnforcer 和 SyncedEnforcer
我们写 enforcer 可能会想到是否需要缓存,是否配置变化能及时更新,这里使用了一个父类和两个子类的方式来实现。把是否使用缓存,是否使用配置的选择权交给用户。而不是简单在一个结构体里面塞上这些功能。
先定义接口
基本上每个可以扩展的结构都考虑到使用接口进行定义。定义接口扩展性提高了,且可以更加丰富了。
adapter
我觉得 persist/adapter 里面这个写法挺好的。
首先它定义了 adapter 这个接口,让实现接口的类来具体实现我从哪个持久化存储里面读取配置文件,但是希望每一行都有统一的读取规则,所以它就把 adapter 接口和 LoadPolicyLine 方法放同一个文件里面。
其次继承结构:
它实现了接口的继承,filterdApapter 接口继承 Adapter,file-filterdAdapter继承了file-Adapter。
如果我们写,有可能就简单定义了一个 filterLine 的函数,它这里更近一步,可以直接设置根据 p 或者 g 的某个字段进行过滤。
if err := e.LoadFilteredPolicy(&fileadapter.Filter{
P: []string{"", "domain1"},
G: []string{"", "", "domain1"},
}); err != nil {
t.Errorf("unexpected error in LoadFilteredPolicy: %v", err)
}
使用起来就大大方便了。
总结
casbin 项目最核心的一定是那篇 PML 的论文。基于理论论文发展出来的这个项目也是非常牛X的。casbin 应该能满足大多数的权限管理系统的要求了。如果 casbin 不能实现你的权限需求的话,我觉得应该先思考下,产品经理提出的需求是不是靠谱的。。。哈哈哈
实时了解作者更多技术文章,技术心得,请关注微信公众号“轩脉刃的刀光剑影”
本文基于署名-非商业性使用 3.0许可协议发布,欢迎转载,演绎,但是必须保留本文的署名叶剑峰(包含链接http://www.cnblogs.com/yjf512/),且不得用于商业目的。如您有任何疑问或者授权方面的协商,请与我联系。