权限控制用 casbin 还是 ladon? casbin 看的头疼

2023-09-14 10:25:36 +08:00
 nobject

纠结使用哪个,个人更倾向于 ladon, 但如果授权策略多的话,ladon 会不会慢?

ladon 的用法:

{
  "description": "One policy to rule them all.",
  "subjects": ["users:<peter|ken>", "users:maria", "groups:admins"],
  "actions" : ["delete", "<create|update>"],
  "effect": "allow",
  "resources": [
    "resources:articles:<.*>",
    "resources:printer"
  ],
  "conditions": {
    "remoteIP": {
        "type": "CIDRCondition",
        "options": {
            "cidr": "192.168.0.1/16"
        }
    }
  }
}

acl 的功能肯定都实现了 主体:可以用前缀代表用户,用户组,角色等, 也算是简单实现了 rbac 吧 条件:一些环境属性,可以通过 condtions 设置主体的属性或者资源的属性, 也算是实现了 abac 吧?

ladon 整体的语义与 aws 的特别像,是不是如果我要做一个类似 aws 的权限操作方式,用这个比用 casbin 更简单易用。

casbin 有 model, policy 两个概念,policy 包含策略信息,model 是规则匹配模板, 如果我一个用户,他既授权了一些带属性的(比如 ip 的判断),类似 abac ,又授权了 rbac 的模型, 那就得用两个 model 与两个 policy?

那 casbin 相比 ladon 来说,他的主要优势在哪呢?灵活性更强?性能更好?

3237 次点击
所在节点    程序员
21 条回复
israinbow
2023-09-14 10:27:32 +08:00
用 casbin 会使你变得不幸.
learningman
2023-09-14 10:35:32 +08:00
casbin 的性能不太行的,特别是 rbac
规则多的情况下最差 O(n^2)
YVAN7123
2023-09-14 10:48:44 +08:00
nobject
2023-09-14 10:58:57 +08:00
@israinbow 这个怎么说?
binyu
2023-09-14 11:04:03 +08:00
原来不止我一个人不喜欢 casbin ,自己写了一套,用着很舒服
yuancoder
2023-09-14 11:06:57 +08:00
casbin 这玩意太复杂了,一个简单的东西搞这么复杂图什么
swulling
2023-09-14 11:08:12 +08:00
casbin 很 low ,千万别用。
snowlyg
2023-09-14 11:09:02 +08:00
功能越多的东西肯定越复杂,casbin 兼容了太多的东西。
nobject
2023-09-14 11:09:17 +08:00
@learningman O(n^2)?这么吓人,他策略文件我记得是 用户与角色一条,角色与规则一条,最差复杂度不是 O(m*n) 么?角色数量 * 规则数量,还是我想差了?
masterclock
2023-09-14 11:21:13 +08:00
OPA
learningman
2023-09-14 11:44:23 +08:00
@nobject 它是邻接表存的图,而且没有做去环,直接靠限制递归深度来判的
Maboroshii
2023-09-14 11:49:39 +08:00
casbin 不好用 不如自己写
Casbin
2023-09-14 12:17:04 +08:00
@nobject

> casbin 有 model, policy 两个概念,policy 包含策略信息,model 是规则匹配模板, 如果我一个用户,他既授权了一些带属性的(比如 ip 的判断),类似 abac ,又授权了 rbac 的模型, 那就得用两个 model 与两个 policy?

RBAC 的语法和 ABAC 的语法可以自行组合到同一个 model 和 policy ,就像编程语言的 for 和 if 可以在同一个程序里写一样

> 那 casbin 相比 ladon 来说,他的主要优势在哪呢?灵活性更强?性能更好?

Casbin 是跨语言平台的,Ladon 应该主要是 Go 语言,Ladon 比较小巧简约,适合中小型系统,如果是小型个人项目,建议用 Ladon 就可以。Casbin 可能更适合大型、企业级的系统。性能的话,如果 policy 内规则条数为 n ,则性能大约为 O(n)。RBAC 角色继承判断有专门的优化,不会增加时间复杂度。
mainjzb
2023-09-14 12:22:23 +08:00
casbin 是真的复杂。。。拿起 1 年前的项目看了一眼。。根本不想改
unfurl
2023-09-14 13:28:47 +08:00
open policy agent
xingjue
2023-09-14 13:37:53 +08:00
timnottom
2023-09-14 13:41:00 +08:00
casbin 的 go 版本,官方 sdk 写得和屎一样,传参全是 interface{}
wangxiaoaer
2023-09-14 14:24:02 +08:00
@xingjue 这个东西在业务系统里面用有没有例子参考?感觉还是有点小复杂。
Or13rs
2023-09-14 17:55:56 +08:00
从 casbin 的 0.8.4 开始用,是个 python 库,上生产了

使用场景确实非常广,但是由于太广,对于抽象的要求非常高,在不同的场景,不管是 ACL 还是 RBAC ,带不带 DOMAIN 的问题,会使策略逻辑的复杂度陡然上升。要想用的舒服,对于 casbin 的抽象逻辑如何 match 业务场景,要自己的抽象能力也很强。简单来说就是理解门槛高高的。

在理解它逻辑的基础上,想要简单使用,最好是对一些复杂逻辑阉割,类似在做黑白名单的时候,要么只做黑要么只做白。

O(n^2)的问题其实不是无解,取决是权限主体多,还是权限对象多,比如用户管理资产,如果用户多,资产少,那按照原始逻辑计算会很快,但是如果用户少,资产多,那么影响很大。
新版本不知道啥情况,当时我们处理的时候,搞了点魔法,因为是多主体多对象的场景,所以我们直接在鉴权之前把主体和对象互换了位置,来提升了点效率。

还有些吐槽的点,就算了
ychost
2023-09-14 18:53:19 +08:00
看了 casbin 的 JAVA 实现,确实性能很拉跨,不过它的理念非常不错,自己参考理念去实现也挺简单的,无非就是一个 拼接 SQL 的过程,建议自己开发,难度也不大

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/973647

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX