Casbin是一个强大且高效的开源访问控制库，支持各种访问控制模型，用于在全局范围内执行授权。

执行一组规则就像在策略文件中列出主题、对象和期望的允许操作（或根据您的需要的任何其他格式）一样简单。 这在所有使用Casbin的流程中都是同义的。 开发者/管理员对布局、执行和授权条件的控制是完全的，这些都是通过模型文件设置的。 Casbin提供了一个Enforcer，用于根据提供给Enforcer的策略和模型文件验证传入的请求。

需要搞清楚两个概念：

  • AuthN 系统主要用于认证 （Authentication），决定谁访问了系统。
  • AuthZ 系统主要用于授权 （Authorization），决定访问者具有什么样的权限。

AuthN 系统是用户登录系统，并且获取用户的身份信息，可以用 JWT 来实现。 AuthZ 系统是根据用户的身份信息，决定用户具有什么权限，可以用 Casbin 来实现。

1 什么是Casbin

Casbin是一个授权库，可以在我们希望某个对象或实体被特定用户或主体访问的流程中使用。 访问类型，即动作，可以是*读取*，写入，删除，或者由开发者设置的任何其他动作。 这就是Casbin最广泛使用的方式，它被称为“标准”或经典的{ 主体, 对象, 动作 }流程。

Casbin能够处理许多复杂的授权场景，而不仅仅是标准流程。 可以添加角色（RBAC），属性（ABAC）等。

1.1 Casbin做什么

  1. 在经典的{ 主体, 对象, 动作 }形式或者你定义的自定义形式中执行策略。 支持允许和拒绝授权。
  2. 处理访问控制模型及其策略的存储。
  3. 管理角色-用户映射和角色-角色映射（也称为RBAC中的角色层次）。
  4. 支持内置的超级用户，如root或administrator。 超级用户可以在没有明确权限的情况下做任何事情。
  5. 提供多个内置操作符以支持规则匹配。 例如，keyMatch可以将资源键/foo/bar映射到模式/foo*。

1.2 Casbin 不做什么

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

1.3 支持的模型

Model Model file Policy file
ACL basic_model.conf basic_policy.csv
ACL with superuser basic_with_root_model.conf basic_policy.csv
ACL without users basic_without_users_model.conf basic_without_users_policy.csv
ACL without resources basic_without_resources_model.conf basic_without_resources_policy.csv
RBAC rbac_model.conf rbac_policy.csv
RBAC with resource roles rbac_with_resource_roles_model.conf rbac_with_resource_roles_policy.csv
RBAC with domains/tenants rbac_with_domains_model.conf rbac_with_domains_policy.csv
ABAC abac_model.conf N/A
RESTful keymatch_model.conf keymatch_policy.csv
Deny-override rbac_with_not_deny_model.conf rbac_with_deny_policy.csv
Allow-and-deny rbac_with_deny_model.conf rbac_with_deny_policy.csv
Priority priority_model.conf priority_policy.csv
Explicit Priority priority_model_explicit priority_policy_explicit.csv
Subject-Priority subject_priority_model.conf subject_priority_policyl.csv

1.4 模型

Casbin中访问控制模型抽象为PERM元模型的 CONF 文件，PERM 模型至少由四个基础部分组成：[request_definition](策略)、[policy_definition](效果)、[policy_effect](请求)和[matchers](匹配器)。 如果模型使用基于角色的访问控制（RBAC），它还应包括[role_definition]部分。

Casbin中最基本和最简单的模型是ACL。 ACL的模型CONF如下：

 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

定义请求参数。 基本请求是一个元组对象，至少需要一个主体（被访问实体），对象（被访问资源）和动作（访问方法）。

例子中，sub，obj和act代表了经典的访问三元组：主体（访问实体），对象（被访问资源）和动作（访问方法）。也可以定义自己的请求格式。

policy_definition

定义访问策略的模型。 它指定了策略规则文档中字段的名称和顺序。

注意：如果未定义eft（策略结果），则不会读取策略文件中的结果字段，匹配策略结果将默认允许。

例子中定义了策略的模型，那么在策略文件中，可以定义相应的策略如：

1

p, alice, data1, read

策略中的每一行都被称为策略规则，每个策略规则都以策略类型开始。

policy_effect

对匹配器的匹配结果进行逻辑组合判断。

如：

  1. e = some(where (p.eft == allow)), 意味着，如果有任何匹配的allow策略规则，最终效果是allow（也称为允许覆盖）。

  2. e = some(where (p.eft == allow)) && !some(where (p.eft == deny)), 意味着，如果有一个策略匹配到允许的结果，并且没有策略匹配到拒绝的结果，结果为真。

  3. e = !some(where (p.eft == deny)),意味着，如果没有匹配到deny策略规则，最终的结果为真。

matchers

定义请求和策略的匹配规则。如示例中的m = r.sub == p.sub && r.obj == p.obj && r.act == p.act，意味着，请求和策略的主体，对象和动作都必须完全匹配。

匹配器中可以使用算术运算符如+, -, *, /和逻辑运算符如&&, ||, !。

role_definition

用于定义 RBAC 角色继承关系。 Casbin 支持多个实例的 RBAC 系统，其中用户可以拥有角色及其继承关系，资源也可以拥有角色及其继承关系。 这两个 RBAC 系统不会相互干扰。 此部分为可选。 如果你在模型中不使用 RBAC 角色，那么省略此部分。