Go语言学习笔记——访问权限控制框架casbin

---

Golang访问权限控制框架casbin

官方文档

https://casbin.org/docs/zh-CN/overview

casbin简介

Casbin 是一个强大的、高效的开源访问控制框架，其权限管理机制支持多种访问控制模型。支持的语言也很多，例如：go、java、node.js、python等等.

Casbin 是什么？

Casbin 可以：

1. 支持自定义请求的格式，默认的请求格式为{subject, object, action}。
2. 具有访问控制模型model和策略policy两个核心概念。
3. 支持RBAC中的多层角色继承，不止主体可以有角色，资源也可以具有角色。
4. 支持内置的超级用户 例如：root 或 administrator。超级用户可以执行任何操作而无需显式的权限声明。
5. 支持多种内置的操作符，如 keyMatch，方便对路径式的资源进行管理，如 /foo/bar 可以映射到 /foo*

Casbin 不能：

1. 身份认证 authentication（即验证用户的用户名和密码），Casbin 只负责访问控制。应该有其他专门的组件负责身份认证，然后由 Casbin 进行访问控制，二者是相互配合的关系。
2. 管理用户列表或角色列表。 Casbin 认为由项目自身来管理用户、角色列表更为合适， 用户通常有他们的密码，但是 Casbin 的设计思想并不是把它作为一个存储密码的容器。 而是存储RBAC方案中用户和角色之间的映射关系。

访问控制模型

控制访问模型有哪几种？我们需要先来了解下这个。

• UGO(User, Group, Other)

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

• ACL(访问控制列表)

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

  setfacl -m user:yejianfeng:rw- ./test
  1

  [yejianfeng@ipd-itstool ~]$ getfacl test
  # file: test
  # owner: yejianfeng
  # group: yejianfeng
  user::rw-
  user:yejianfeng:rw-
  group::rw-
  mask::rw-
  other::r--
  1
  2
  3
  4
  5
  6
  7
  8
  9

  当我们使用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}}
  1
  2
  3
  4

  这个权限验证模型的好处就是扩展性好，一旦要增加某种权限，就可以直接增加某种属性。

• DAC（自主访问控制）

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

  比如我们常用的windows就是用这么一种方法。

• MAC(强制访问控制)

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

简单使用

安装

go get github.com/casbin/casbin
go get github.com/casbin/casbin/v2 // 可能兼容还有问题

go get github.com/casbin/gorm-adapter

go get github.com/go-sql-driver/mysql

go get github.com/jinzhu/gorm
1
2
3
4
5
6
7
8

创建model配置文件

model.conf

# 请求定义
[request_definiation]
r = sub,obj,act
# sub ——> 想要访问资源的用户角色(Subject)——请求实体
# obj ——> 访问的资源(Object)
# act ——> 访问的方法(Action: get、post...)


# 策略定义
# 策略(.csv文件p的格式，定义的每一行为policy rule;p,p2为policy rule的名字。)
[policy_definiation]
p = sub,obj,act
# p2 = sub,act 表示sub对所有资源都能执行act


# 组定义
[role_definiation]
g = _, _
# g = _,_定义了用户——角色，角色——角色的映射关系，前者是后者的成员，拥有后者的权限。
# _,_表示用户，角色/用户组


# 策略效果
[policy_effect]
e = some(where(p.eft = allow))
# 上面表示有任意一条 policy rule 满足, 则最终结果为 allow；p<
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25