gin框架学习-Casbin入门指南(ACL、RBAC、域内RBAC模型)

lin钟一

已于 2022-09-07 18:22:47 修改

阅读量2.8k

点赞数 4

分类专栏： gin框架学习文章标签： go java php python c++

于 2022-07-13 17:14:11 首次发布

本文链接：https://blog.csdn.net/weixin_46618592/article/details/125765111

版权

本文详细介绍了Casbin访问控制框架，包括其工作原理、模型语法、请求定义、策略定义、匹配器、策略效果以及RBAC和域内RBAC模型。Casbin支持自定义请求格式、多种访问控制模型，并提供了灵活的角色继承。它不负责身份认证，但能与其他认证组件配合实现全面的权限管理。

摘要由CSDN通过智能技术生成

前言

感谢开源项目gin-vue-admin，以及1010工作室的视频教程
本人学识尚浅，如有错误，请评论指出，谢谢！
详细可见个人博客：https://linzyblog.netlify.app/

一、Casbin概述

Casbin 是一个强大的、高效的开源访问控制框架，其权限管理机制支持多种访问控制模型。
Casbin参考文档链接：https://casbin.org/
github项目链接：https://github.com/casbin/casbin

Casbin 可以：

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

Casbin 不能：

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

二、Casbin工作原理

在 Casbin 中, 访问控制模型被抽象为基于 PERM (Policy, Effect, Request, Matcher) 的一个文件。因此，切换或升级项目的授权机制与修改配置一样简单。您可以通过组合可用的模型来定制您自己的访问控制模型。例如，您可以在一个model中结合RBAC角色和ABAC属性，并共享一组policy规则。

PERM模式由四个基础 (Policy, Effect, Request, Matcher) 组成，描述了资源与用户之间的关系。

三、Model语法

Model CONF 至少应包含四个部分: [request_definition], [policy_definition], [policy_effect], [matchers]。
如果 model 使用 RBAC, 还需要添加 [role_definition] 部分。
Model CONF 文件可以包含注释。注释以 # 开头， # 会注释该行剩余部分。

1、Request定义

Request 定义请求参数。基本请求是一个元组对象，至少需要主题(访问实体)、对象(访问资源) 和动作(访问方式)

例如，一个请求可能长这样： r={sub,obj,act}
它实际上定义了我们应该提供访问控制匹配功能的参数名称和顺序。

[request_definition] 部分用于request的定义，它明确了 e.Enforce(…) 函数中参数的含义。

[request_definition]
r = sub, obj, act

sub, obj, act 表示经典三元组: 访问实体 (Subject)，访问资源 (Object) 和访问方法 (Action)。但是, 你可以自定义你自己的请求表单, 如果不需要指定特定资源，则可以这样定义 sub、act ，或者如果有两个访问实体, 则为 sub、sub2、obj、act。

2、Policy定义

Policy 定义访问策略模式。事实上，它是在Policy规则文件中定义字段的名称和顺序。

例如： p={sub, obj, act} 或 p={sub, obj, act, eft}
注：如果未定义eft (policy result)，则策略文件中的结果字段将不会被读取，和匹配的策略结果将默认被允许 allow。

[policy_definition] 部分是对policy的定义，以下文的 model 配置为例:

[policy_definition]
p = sub, obj, act
p2 = sub, act

这些是我们对policy规则的具体描述

p, alice, data1, read
p2, bob, write-all-objects

policy部分的每一行称之为一个策略规则，每条策略规则通常以形如p, p2的policy type开头。如果存在多个policy定义，那么我们会根据前文提到的policy type与具体的某条定义匹配。上面的policy的绑定关系将会在matcher中使用，罗列如下：

(alice, data1, read) -> (p.sub, p.obj, p.act)
(bob, write-all-objects) -> (p2.sub, p2.act)

3、Matcher定义

Matcher 匹配请求 Request 和策略 Policy 的规则。

例如： m = r.sub == p.sub && r.act == p.act && r.obj == p.obj
这个匹配规则意味着如果请求Request的参数(访问实体，访问资源和访问方式)匹配，可以在策略 Policy 中找到资源和方法，那么策略 Policy 结果（p.eft）便会返回。策略的结果将保存在 p.eft 中。

[matchers] 是策略匹配程序的定义。匹配程序是表达式。它定义了如何根据请求评估策略规则。