简介
Casbin可以做到:
- 支持自定义请求的格式,默认的请求格式为{subject, object, action}。
- 具有访问控制模型model和策略policy两个核心概念。
- 支持RBAC中的多层角色继承,不止主体可以有角色,资源也可以具有角色。
- 支持超级用户,如 root 或 Administrator,超级用户可以不受授权策略的约束访问任意资源。
- 支持多种内置的操作符,如 keyMatch,方便对路径式的资源进行管理,如 /foo/bar 可以映射到 /foo*
Casbin不能做到:
- 身份认证 authentication(即验证用户的用户名、密码),casbin只负责访问控制。应该有其他专门的组件负责身份认证,然后由casbin进行访问控制,二者是相互配合的关系。
- 管理用户列表或角色列表。 Casbin 认为由项目自身来管理用户、角色列表更为合适, 用户通常有他们的密码,但是 Casbin 的设计思想并不是把它作为一个存储密码的容器。 而是存储RBAC方案中用户和角色之间的映射关系。
实现原理
Casbin 中, 访问控制模型被抽象为基于 PERM (Policy, Effect, Request, Matcher) 的一个文件
基本的配置文件示例如下所示:
# Request definition
[request_definition] r = sub, obj, act
# Policy definition [policy_definition]
p = sub, obj, act,efc
# Policy effect
[policy_effect] e = some(where (p.eft == allow)) && !some(where (p.eft == deny))
# Matchers
[matchers] m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
request_definition
: 表示验证权限请求所需要的参数,分别为 sub表示请求方是谁,obj表示请求的作用对象是谁,act要对作用对象做些什么。大体上为张三要吃苹果 sub表示张三,obj表示苹果,act表示吃。
policy_definition
:表示验证策略权限的配置表如下所示。
matcher
表示验证方法:定义了如何根据请求评估策略规则。
policy_effect
:对policy生效范围的定义, 原语定义了当多个policy rule同时匹配访问请求request时,该如何对多个决策结果进行集成以实现统一决策
假设规则如下所示:
- 配置表:p如下:sub, obj, act,efc #策略结果
匹配表如下:
p, 张三, 苹果, 吃 ,allow
p, 张三,苹果,吃,deny
- 请求如下:
e.Enforce(张三,苹果 , 吃)
- 匹配策略表
根据matcher
两条数据有两个结果allow
和deny
policy_effect
按规则多个结果是,结果为allow
并且结果不为deny
时允许。
返回结果为false
Casbin还提供多角色和域角色大体实现如下
角色:
表示用户角色
[role_definition] g = _, _ g2 = _, _
域租户角色:
表示用户区域角色
[role_definition] g = _, _, _
matcher中的函数
matcher的强大与灵活之处在于您甚至可以在matcher中定义函数,这些函数可以是内置函数或自定义的函数。当前支持的内置函数如下,具体用法参考官方文档:keyMatch(arg1, arg2)
路径参数匹配regexMatch(arg1, arg2)
正则表达式匹配ipMatch(arg1, arg2)
ip匹配
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。