上次介绍了权限系统的设计 后,这次我们来说说如何实现系统的实现。

复习一遍上次提到的内容,我们知道:

权限就是规定谁可以对什么资源进行什么样的操作。

那么,权限引擎就是根据这个原则来进行设计,于是,就引出了我们今天想介绍的工具:casbin

不过,今天想换种方式,如果我们自己要做个权限引擎,改如何实现呢?

假如我们自己实现

我们的需求

  1. 与具体业务场景无关,即所有的角色、资源以及操作都是抽象的;
  2. 适应任何权限模型,如 ACL,RBAC、ABAC;
  3. 管理相关的存储;

功能

我们理想中的情况就是:可以在中间件中,统一对用户进行鉴权,如果没有权限,中止继续访问,返回 HTTP status code 403,而如果有权限,则放行。

那么,再具体细化,就是这个权限引擎应该给我们提供至少以下几个接口:

  • 判断某个用户 ID 是否具有权限;
  • 管理用户角色,甚至角色组;
  • 管理角色的权限,即可以对那些资源进行什么样的操作;

实现

在这个模型中,有三种实体:

  • 角色:subject(用户可以与角色合并成为 subject,于是角色组也可以表示了);
  • 资源:object;
  • 操作:action;

然后,就是它们的关系,我们可以分为模型与规则,模型即 ACL、RBAC 等,而规则会涉及到具体业务对象,可以理解为模型相当于代码,而规则代表数据,比如在 RBAC 中,规定哪个用户会有什么角色,哪个角色可以对具体的资源进行什么操作等等。

好了,大致的需求就到此,因为往深了说就没完了,而这些简单的功能,我们都可以在自己的系统中去实现,毕竟如何运行都明白了。

只是, 我们往往会做得跟业务比较耦合,因为一旦需要做个普适性的权限引擎,这点是完全不够的,你需要根据模型与规则,编写一套相应的规则引擎 。所以,还是回到我们今天的主角,我们现在来看看 casbin 是如何实现的。

Casbin 的介绍

正如上面所说,它把模型称为 model,而规则称为 policy。

Model

一个具体的 RBAC model:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Request definition
[request_definition]
r = sub, obj, act

# Policy definition
[policy_definition]
p = sub, obj, act

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

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

我们可以看到,Request definition 即为请求定义,代表了你可以传入什么样的参数来确定权限,而 Policy definition 代表了规则的组成,这两处也就是我上面说的,这个模型规定了,谁 (sub) 可以对什么资源 (obj) 进行什么操作(act)。

Policy effect 则表示什么样的规则可以被允许,e = some(where (p.eft == allow)) 这句就表示当前请求中包含的任何一个规则被允许的话,这个权限就会被允许,而反过来,假如是 e = !some(where (p.eft == deny)) 则表示,只要有一个规则被拒绝了,这个权限请求就会被拒绝,也就是说所有的规则都要被允许才能继续。

Matchers 表示请求与规则是如何起作用的,上面配置中的例子告诉我们,只有当请求与规则的 sub、obj、act 都相匹配的情况下,这条规则才会被批准。

Policy

与上面的模型相对应的规则,可以这样来写:

1
2
p, alice, data1, read
p, bob, data2, write

这两条记录就表示,alice 可以对 data1 进行读取,而 bob 可以对 data2 进行写入,那么接口的判断条件可以类似于这样的接口: isAllow('alice', 'data1', 'read')

在项目中使用

下面我们以 Golang 来简单说说如何在我们的项目中使用。

很简单:

1
e := casbin.NewEnforcer("path/to/model.conf", "path/to/policy.csv")

这句就是初始化了,然后:

1
2
3
4
5
if e.Enforce(sub, obj, act) {
// 允许继续操作
} else {
// 拒绝请求
}

是不是很简单呢?

在实际使用过程中,我们可以将这个步骤封装到一个中间件内统一处理,大致原理是将用户的 ID 与角色进行绑定,然后用 Enforce 来判断每次用户的请求是否被允许。

而当我们的系统是 Web 系统时,就更方便了,尤其是 RESTful 接口,每一个路径都是资源,而操作就是 GET, POST, PUT, DELETE 等。

对应例子可以利用 casbin 的内建函数来处理,将模型中的 matchers 改为:

1
2
[matchers]
m = r.sub == p.sub && keyMatch2(r.obj, p.obj) && regexMatch(r.act, p.act)

对应的规则改为:

1
2
3
p, role1, /users/:id, GET
p, role2, /users/:id, POST
p, role3, /articles, .+

存储

我们可以看到,它默认的规则存储在 CSV 文件中,但是也可以存储在其它地方,比如各种数据库,具体可以去 policy-storage 查看。

其他

Casbin 目前支持多种语言,以及多种储存,更重要的上面我提到的几种权限模型它都支持,可以说是非常强大了。

假如是微服务,它也可以作为一个独立的权限微服务或者 API 网关的模块存在:https://casbin.org/docs/en/service。

核心代码其实是基于 github.com/Knetic/govaluate 来实现的,有兴趣的可以去看看


首发于 Github issues: https://github.com/xizhibei/blog/issues/102 ,欢迎 Star 以及 Watch

本文采用 署名-非商业性使用-相同方式共享(BY-NC-SA)进行许可
作者:习之北 (@xizhibei)
原链接:https://blog.xizhibei.me/2019/03/24/authorization-engine-casbin/