Java 有现成的权限系统框架么？

[tctc4869]

之前自己开发 web 项目的时候，关于权限系统的编码，自己从 0 开始编写了一个简易的权限系统，基于 RBAC 的那种，不过还是想看看有没有现成的权限系统设计。

现在的我不太喜欢注解配置，注解侵入太强，想找一套式非侵入式的权限系统框架，权限校验在类似 Web 拦截器之类的地方进行权限校验。各位知道有哪些现成的么，或者有什么思路么

至于是哪个 WebMVC 框架，这里不说明，因为 WebMVC 框架可能使用的是 Spring MVC,也可能是 Vert.x web,也可能是 JFinal,也可能是 Servlet 。所以侵入程度不要太强。尽可能与 WebMVC 的代码解耦。这是一个重点。

权限校验代码不能写在 Controller 类里，所以 shiro 之类通过注解的方式实现权限校验的方式被排除了，如果有 Controller 需要特定的权限校验，那这个交给拦截器之类的组件来进行。

[safilar]

@tctc4869 其实就是重写一个拦截器，将接口上的注解直接映射到 redis，这里需要自己建存储。然后统一由拦截器读取配置，这里用 spring Security 举例子重写 AccessDecisionManager decide 的方法。第一个参数 Authentication 是你自定义的权限集合（一般读表）；第二个参数，一般取 request 用的，

[safilar]

第三个参数 urlConfigAttribute 用户传递过来的 uri，你通过这个方法直接鉴权；如果是权限路由表是 pathvariable 这种，你就可以使用 AntPathRequestMatcher spring 自带的识别器来做权限识别是否匹配。

[safilar]

无论是 rbac 还是 abac 这种方式实现都是比较简单，至少注解不用写了。

[wangxiaoaer]

@BQsummer abac 结合 spring expression 我觉得有搞头。

[tctc4869]

@safilar
没用过 abac 权限模型，abac 相对 RBAC 简单么？我记得这个有网站说 abac 比 rbac 权限模型，要复杂。是这样的么？

[xuanbg]

@tctc4869 你这个需求其实是多租户体系的典型应用。对于多租户体系来说，每个租户都有独立的角色权限管理。譬如淘宝店铺后台就是个多租户应用，钉钉也是。我们都是阿里的用户，在我们注册店铺后，店铺就是阿里的租户，我们既是阿里的普通用户，也是店铺这个租户的管理用户。

这些概念对于没深入有研究过权限管理系统的人来说可能稍复杂，但可以简单看一下 https://github.com/xuanbg/auth 这个项目里面的表结构。

[xuanbg]

@xuanbg 上面链接给错了，看着来吧： https://github.com/xuanbg/insight_auth/blob/master/insight_base.sql

[tctc4869]

@xuanbg 根据你所说的，ABAC 权限体系的用途上，我感觉，就是基于平台应用级别的权限系统，不同的组织，在这个平台上，可以有不一样的权限体系。至少每个组织对内权限体系，可以不一样。而 RBAC 权限模型做不到这一点，至少如果有两个客户群体有不一样的权限需求，RBAC 实现起来就会很困难。是这样的么？

[xuanbg]

@tctc4869
权限其实就是资源的分配，而资源的集合就是应用。最原始的 RBAC，只是不考虑多租户，而且是单应用的权限数据模型。

而在多租户多应用体系里面，你所谓的客户群体，本质上都是用户而已。你把他们看做两个群体，实际上不过是他们是两个应用的用户罢了。

我项目里面的 role 表中，tenant_id 表示角色的租户归属，app_id 表示角色的应用归属。也就是同样应用的管理员，A 租户和 B 租户是两个角色，他们各管各的且互相不可见。

具体的关系，你看我这篇博客就明白了。https://www.cnblogs.com/xuanbg/p/12511509.html

[fox0001]

权限应该分为功能权限和数据权限。

功能权限的话，filter （ Web 拦截器）应该是比较适合了。

数据权限的话，很大程度依赖根据业务逻辑而设计的数据结构。

[Shikyou]

@hantsy 也可以试一下国内的 Authing 。
authing.cn 和 cognito / auth0 / okta 差不多，可以快速实现用户的 ABAC 和 RBAC

[hantsy]

@Shikyou AUTHING.CN 这种方向不错，不过国内推广应该没有国外那么容易。以前在项目推荐过 Stormpath （后来被 Okta 收购了）。国内的对于推荐一些方案如果他们自己没有弄过的，基本上我之前一些帖子见到那些言论一样，“用这个出了问题来谁背锅”，“你不能证明这个我们用的更好，为什么要换掉现成的东西”，“迁移到其它平台风险你能评估出来吗，这个工作量算谁的”。国内公司家长式的管理模式，培养都是一些巨婴一样的员工，不管什么方案，对于他们只要不要他们重新学习，不要他们动手就是最好的方案，每天用用 Copy，Paste 就完成工作就好了。

接触国外到项目，自己没太多要求的基本都是走一下 JWT Token 完成了，有社交账号支持要求的，多种形式认证（ 2fa, otp 等）的基本最终上线选择 okta 或 outh0 这些成熟方案比较多，有些使用的 API 或者方案是自己都是集成身份认证了，比如 Firebase 。开发过程中可能就是直接用一个 Basic Http 认证，对于大部分功能写测试比较简单。

[Shikyou]

@hantsy 草。分析得太对了。感谢对 Authing 的认可，我们在小范围推广 ing

[hsluoyz]

推荐下 jCasbin： https://github.com/casbin/jcasbin 支持 ACL 、RBAC 、ABAC 等访问控制模型