这是一个创建于 470 天前的主题，其中的信息可能已经有所发展或是发生改变。
纠结使用哪个，个人更倾向于 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 来说，他的主要优势在哪呢？灵活性更强？性能更好？
 |
1
israinbow 2023-09-14 10:27:32 +08:00 via Android  8
用 casbin 会使你变得不幸.
|
 |
2
learningman 2023-09-14 10:35:32 +08:00 via Android
casbin 的性能不太行的，特别是 rbac
规则多的情况下最差 O(n^2) |
 |
5
binyu 2023-09-14 11:04:03 +08:00
原来不止我一个人不喜欢 casbin ，自己写了一套，用着很舒服
|
 |
6
yuancoder 2023-09-14 11:06:57 +08:00
casbin 这玩意太复杂了，一个简单的东西搞这么复杂图什么
|
 |
7
swulling 2023-09-14 11:08:12 +08:00
casbin 很 low ，千万别用。
|
 |
8
snowlyg 2023-09-14 11:09:02 +08:00
功能越多的东西肯定越复杂，casbin 兼容了太多的东西。
|
 |
9
nobject OP @learningman O(n^2)？这么吓人，他策略文件我记得是 用户与角色一条，角色与规则一条，最差复杂度不是 O(m*n) 么？角色数量 * 规则数量，还是我想差了？
|
 |
10
masterclock 2023-09-14 11:21:13 +08:00
OPA
|
|
11
learningman 2023-09-14 11:44:23 +08:00 via Android
@nobject 它是邻接表存的图，而且没有做去环，直接靠限制递归深度来判的
|
 |
12
Maboroshii 2023-09-14 11:49:39 +08:00 via Android
casbin 不好用 不如自己写
|
 |
13
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 角色继承判断有专门的优化，不会增加时间复杂度。 |
 |
14
mainjzb 2023-09-14 12:22:23 +08:00
casbin 是真的复杂。。。拿起 1 年前的项目看了一眼。。根本不想改
|
 |
15
unfurl 2023-09-14 13:28:47 +08:00
open policy agent
|
 |
16
xingjue 2023-09-14 13:37:53 +08:00
|
 |
17
timnottom 2023-09-14 13:41:00 +08:00 1
casbin 的 go 版本，官方 sdk 写得和屎一样，传参全是 interface{}
|
 |
18
wangxiaoaer 2023-09-14 14:24:02 +08:00 via iPhone
@xingjue 这个东西在业务系统里面用有没有例子参考？感觉还是有点小复杂。
|
 |
19
Or13rs 2023-09-14 17:55:56 +08:00 1
从 casbin 的 0.8.4 开始用，是个 python 库，上生产了
使用场景确实非常广，但是由于太广，对于抽象的要求非常高，在不同的场景，不管是 ACL 还是 RBAC ，带不带 DOMAIN 的问题，会使策略逻辑的复杂度陡然上升。要想用的舒服，对于 casbin 的抽象逻辑如何 match 业务场景，要自己的抽象能力也很强。简单来说就是理解门槛高高的。 在理解它逻辑的基础上，想要简单使用，最好是对一些复杂逻辑阉割，类似在做黑白名单的时候，要么只做黑要么只做白。 O(n^2)的问题其实不是无解，取决是权限主体多，还是权限对象多，比如用户管理资产，如果用户多，资产少，那按照原始逻辑计算会很快，但是如果用户少，资产多，那么影响很大。 新版本不知道啥情况，当时我们处理的时候，搞了点魔法，因为是多主体多对象的场景，所以我们直接在鉴权之前把主体和对象互换了位置，来提升了点效率。 还有些吐槽的点，就算了 |
 |
20
ychost 2023-09-14 18:53:19 +08:00
看了 casbin 的 JAVA 实现，确实性能很拉跨，不过它的理念非常不错，自己参考理念去实现也挺简单的，无非就是一个 拼接 SQL 的过程，建议自己开发，难度也不大
|
 |
21
gniviliving 2023-09-15 08:15:37 +08:00
casbin 是前段时间一直霸占置顶位置的那个吗，对它就没好感了
|
Select Language