ladon & casbin 两个 authorization 库的比较

ladon_vs_casbin.md

通览了 casbin 的文档，结合先前对 AWS IAM 的理解，以及对 ladon SDK 的使用，总结对比一下 Ladon & Casbin 两个授权库。

1. 项目定位

先对比两个项目的简介：

ladon

A SDK for access control policies: authorization for the microservice and IoT age. Inspired by AWS IAM policies. Written for Go.

casbin

An authorization library that supports access control models like ACL, RBAC, ABAC in Golang

二者都明确自己扮演的是 authorization 的角色，是 4A 中关键一环：

• Authentication
• Authorization ✅
• Accounting
• Audit

2. 哪个功能更全、更多？

casbin 支持 ACL、RBAC、ABAC，而 ladon 仅支持 ACL。ladon 具备 Audit 能力，会对每次请求判断输出结构化的日志信息，casbin 没有。

3. 易用性 & 灵活性 & 扩展性

如果要求尽快投入生产使用，casbin 一定是最好的选择，其有 toml 格式的 Policy Model 文件，和 CSV 格式的 Policy list 文件，程序启动的时候自动导入，即可能够对请求做权限判断了，官方甚至还提供了策略展示的 UI 界面。

然而使用 ladon 的话，则需要对 AWS IAM 体系有所了解，并结合自己的业务稍作调整才能使用。

casbin 对开箱即用者是十分灵活的，其可以通过 Model 文件来配置访问控制的逻辑判断，比如一个请求匹配到了多个策略，则可以设置为 allow-override 机制，也可以设置为 deny-override 机制。而 ladon 则是完全遵循 AWS 的风格：一否全否，除非改源代码，否则不能适应其他要求。

对于数据的持久化来讲，两个库都有 interface 来支持自定义持久化方法。由于 ladon 自身只支持 ACL ，所以其默认提供的持久化方案在 RBAC 要求下是不可用的。casbin 的有官方和第三方持久化实现，但没有真正的测试使用。

总结

ladon 借鉴 AWS IAM 提供了一个策略判断的内核，casbin 则在访问控制的每个环节都提供了现成的方案，甚至还有一个 UI 界面。一个可以基于内核随意在上层自定义开发，另一个则需要踩坑的地方还有不少。

@andyyumiao 有沒有實際案例啊?

@andyyumiao 有沒有實際案例啊?

强烈推荐CNCF今年毕业的策略引擎OPA（维护团队主要是Google、微软、Styra等），可以用来实现ABAC、RBAC、PBAC等各种权限模型，目前我们已经在生产环境使用。另外Ladon的决策内核也是基于OPA实现的。
地址：https://github.com/open-policy-agent/opa

@andyyumiao 讚喔，感謝您提供另一種解決方案。

剛寫完一篇:『初探 Open Policy Agent 實作 RBAC (Role-based access control) 權限控管』，馬上就看到 Casbin 團隊來這邊留言。

非常感謝 @andyyumiao 建議，及 @hsluoyz 對於 Casbin 社區的貢獻。將來有機會一定要寫一篇 Casbin 跟 Open Policy Agent 的比較文

@andyyumiao Hi, 我是casbin作者，来这里既是代表社区向你表达歉意，同时也想解释一下问题所在。我不是来甩锅的，这个锅我们好好背下来：

2.casbin那些库的质量真的是无力吐槽，都没有经常测试的东西就往github发，UI也是到处bug，全都是毕业生写的一样，试用便知

这个可能指的是Casbin-Dashboard这个项目，你当时提了至少2个issue：

• casbin/casbin-dashboard#95
• casbin/casbin-dashboard#96

这个项目确实我们新推出的实验性项目，我们没有在README里标明beta。并且当时主要负责该项目的社区成员和维护者确实经验不够丰富，能力不足，导致该项目烂尾，这个结果我们在社区内部也进行了反思。现在我们已经把该项目关掉（Archive）了，并且不再让相关成员担任repo主要负责人。作为社区，我们错在没有及时告知用户使用该项目可能的风险，导致一些用户浪费了一些时间在上面，这个锅我们背。

3.casbin这个项目不让提问题，提问题就给你关闭，作者很排斥别人提问题

你当时提了至少这3个issue，

• casbin/etcd-watcher#7
• casbin/casbin-server#41
• casbin/casbin-server#42

我们确实关闭你的issue过于草率，这里我代表社区向你表达歉意。当时主要是考虑到在短短几天内，你提了多个（5+）issue，这本是好事，但是我们发觉大部分issue的内容属于随手看下文档都能了解的问题，比如 casbin/etcd-watcher#7 ，我们watcher插件都已经很多了，然后问题是为什么要有watcher这个东西。还有 casbin/casbin-server#42 ，其实在README里已经写了暴露的是gRPC API，issue的问题却是能不能支持HTTP xxx的连续发问。

当然，我们社区规定issue可以用来提问题。然后关于问题，也不能说好问题就是问题，不那么好的问题就不是问题了，就不用回答了。这一点确实当时社区的做法欠缺考量。当然，我理解，作为国内的互联网从业者，时间是很珍贵的，可能不想花太多时间深入文档去了解，可能更希望问一句话，及时得到确切的反馈，以帮助自身决策。这一点我们现在理解地更加深刻。其实现在来看，当时交流更好的形式，可能是你来直接加入我们的QQ群，然后几个对话的来回，也就解答了上面几个issue的问题。可能GitHub issue还是适合那种比较长篇的、贴代码的、比较深入的问题。现在你的几个issue，我都一一进行了回复，并且我们也欢迎你继续来社区提问，我们会一一作答。

目前，我也亲自在带Casbin-Dashboard这个项目的继任者： https://github.com/casbin/casdoor （目前还在开发中），并且我们会首先dogfood，把它用在我们社区自己的线上服务中，而不是提供给用户一些零散的、不成熟的方案。我个人非常关注代码质量，会保证该项目落到实处，也欢迎大家的监督。

最后，很遗憾这次Casbin没有给你带来良好的体验。未来我们会改进失误，进取努力，继续打磨好Casbin产品，服务广大的互联网开发者。

hsluoyz
Casbin社区

@hsluoyz, 很荣幸收到这么权威的回复，我想现在casbin社区应该发生了很大转变。因为当时我们迫切需要一个权限系统来支撑我们生产场景的使用，当时态度有些过激和急躁，可能我自己的行为也伤害到了开源，对此感到抱歉。
目前我了解到相对成熟的开源权限系统可能只有casbin和OPA了，但其实大家都希望有更多优秀的开源项目，我本身也是开源的受益者，同时也希望casbin社区越来越好。

可以使用 casbin 实现类似 AWS 的 IAM 吗。

@andyyumiao Hi, 我是casbin作者，来这里既是代表社区向你表达歉意，同时也想解释一下问题所在。我不是来甩锅的，这个锅我们好好背下来：

2.casbin那些库的质量真的是无力吐槽，都没有经常测试的东西就往github发，UI也是到处bug，全都是毕业生写的一样，试用便知

这个可能指的是Casbin-Dashboard这个项目，你当时提了至少2个issue：

• casbin/casbin-hub#95
• casbin/casbin-hub#96

这个项目确实我们新推出的实验性项目，我们没有在README里标明beta。并且当时主要负责该项目的社区成员和维护者确实经验不够丰富，能力不足，导致该项目烂尾，这个结果我们在社区内部也进行了反思。现在我们已经把该项目关掉（Archive）了，并且不再让相关成员担任repo主要负责人。作为社区，我们错在没有及时告知用户使用该项目可能的风险，导致一些用户浪费了一些时间在上面，这个锅我们背。

3.casbin这个项目不让提问题，提问题就给你关闭，作者很排斥别人提问题

你当时提了至少这3个issue，

• casbin/etcd-watcher#7
• casbin/casbin-server#41
• casbin/casbin-server#42

我们确实关闭你的issue过于草率，这里我代表社区向你表达歉意。当时主要是考虑到在短短几天内，你提了多个（5+）issue，这本是好事，但是我们发觉大部分issue的内容属于随手看下文档都能了解的问题，比如 casbin/etcd-watcher#7 ，我们watcher插件都已经很多了，然后问题是为什么要有watcher这个东西。还有 casbin/casbin-server#42 ，其实在README里已经写了暴露的是gRPC API，issue的问题却是能不能支持HTTP xxx的连续发问。

当然，我们社区规定issue可以用来提问题。然后关于问题，也不能说好问题就是问题，不那么好的问题就不是问题了，就不用回答了。这一点确实当时社区的做法欠缺考量。当然，我理解，作为国内的互联网从业者，时间是很珍贵的，可能不想花太多时间深入文档去了解，可能更希望问一句话，及时得到确切的反馈，以帮助自身决策。这一点我们现在理解地更加深刻。其实现在来看，当时交流更好的形式，可能是你来直接加入我们的QQ群，然后几个对话的来回，也就解答了上面几个issue的问题。可能GitHub issue还是适合那种比较长篇的、贴代码的、比较深入的问题。现在你的几个issue，我都一一进行了回复，并且我们也欢迎你继续来社区提问，我们会一一作答。

目前，我也亲自在带Casbin-Dashboard这个项目的继任者： https://github.com/casbin/casdoor （目前还在开发中），并且我们会首先dogfood，把它用在我们社区自己的线上服务中，而不是提供给用户一些零散的、不成熟的方案。我个人非常关注代码质量，会保证该项目落到实处，也欢迎大家的监督。

最后，很遗憾这次Casbin没有给你带来良好的体验。未来我们会改进失误，进取努力，继续打磨好Casbin产品，服务广大的互联网开发者。

hsluoyz Casbin社区

@hsluoyz 看到你的回答，以为你们真的想转变。但是实际加群的体验还不如在github 提issue，群加了一个又一个，提问题没人回复也就算了，负责回复的人员素质真的有待提高（群主：洛川），问问题的时候只是多提供了些信息，就说不要发乱七八糟的东西，上上强度对线就踢人。就这态度我真的怀疑是不是真的想把社区维护好。加了那么多开源社区的群，第一次有这样的经历