企业系统的权限管理是怎么实现的

[armoni]

遇到一个2B零售管理项目，涉及到复杂的权限管理问题，调研了下RBAC还是抓不着点。
1.需要控制粗粒度资源，如 [客户] ，有的角色页面上不能看到，知道URL打开也要重定向到其他页面，如果Curl或API方式打开，则返回未授权。
2.需要控制细粒度操作，如 [客户] 的 [删除] 功能，控制方式也是页面隐藏功能，页面URL和网络也控住
3.如何遇基于权限来在前端页面隐藏或禁用控件？
3.动态权限，如上海的领导可以看到自己在上海的员工信息，天津的领导只能看到天津员工信息，如果有同事和自己一组，那么只能修改、查看供应信息，不能删除。

对于如何降低业务代码和权限的耦合性有的迷茫，直接上会包含太多的if else, 借这个机会也像大家学习下

shiro能解决上门的问题吗，刚搜到，还在看文档。

目前架构采用rest API + angular的方式， 只能根据权限从后台输出内容到前台显示，无法用到jsp标签控制渲染内容。先研究下Shiro和基于角色的访问控制。

[vilic]

我觉得可以把相关操作的权限分成两个部分, 一个是 scope, 一个是细化的权限. 细化的权限用类似于位运算的方式进行检测, 整个权限判定返回一个布尔值就可以了, 具体也不会很复杂, 前后端都可以这样.

[learnshare]

1L 说得对。

1. 对用户可以进行角色分组（管理员、商户、客户等），每个角色有一个权限列表；
2. API/操作可以按照系统或者模块来划分权限组（商品、订单、账户等），每个权限组有增删改等一系列 API；
3. 把 2 的权限划分到 1 的组中，done。

[virusdefender]

用户组对应权限 在中间层处理 而不是在具体的业务逻辑

[caixiexin]

Shiro 应该可以，就是它的权限标志符的方式还有认证流程不好理解。它自带jsp权限控制 标签，目前自己做的后台系统也可以做到按钮级别的控制了

[zkd8907]

这个还是要看使用的语言或者框架的。
比如之前我写ASP.NET MVC的时候，是自定义了一处RightAttribute，添加在对应的Action方法上。Session启动以后，会去读取用户所对应的权限组，拉取到这个组包含的权限名称。然后在用户每次访问Action的时候先去判断当前Action是否在用户的权限组里。
简单拆开来的逻辑就是：
每个Action（对应的每个cgi）定义一个唯一的权限标识。
创建权限组，可以包括多个权限标识或子权限组。
权限组对应的用户在登录的时候拉取到对应的权限信息并放在Session中。
限制Action在执行的时候先验证权限。

[zts1993]

做GreenCMS的时候，做了个模板标签 根据角色进行限制是否显示区域，同时RBAC验证节点

[invite]

访问控制模型还是很复杂的.

[JamesRuan]

明确在哪一个层面去解决这个问题。

前端层面是不安全的，所以3的需求实现就会有困难了。前后端传递的数据结构需要特别设计。

后端逻辑来说，我在设计的学校论坛系统中也遇到了很极品的权限控制要求；我的设计是这样的，可以实现各种粒度的权限控制，动态权限控制：

一个操作分为三部分：操作者A、被操作对象B、操作行为C。
需要完整记录一个操作的权限，需要一个以AxBxC作为主键的权限表，这个显然是不现实的。

其中，被操作对象允许的操作行为是相对固定的，而操作者与其它两者的关系相对不固定。
于是，我设计中，每一个被操作对象都绑定了一个操作者到操作行为间关系的权限列表。
操作对象按照操作对象的不同，在不同的权限组中。

比如，要求每个帖子的发帖人（author）可以修改帖子，但不能删除帖子，我的权限列表保存为：
edit: author
! delete: author
其中，author是一个用户组，其中的成员对于每一个帖子都不同，只是恰巧叫了同一个名字。
逻辑判断时，查找比对this_post.author，this_post.parent.author，直至查询到根节点，如果这一系列的author用户组中任意一个存在当前用户，则编辑帖子（edit）的行为就可以执行。

[JamesRuan]

另，我这部分设计的文档还没有写完，只有一部分放出来，有兴趣可以参考下
https://github.com/cc98-frontend-development/API/

[BoiledEgg]

Shiro完全可以。看任何一个Shiro教程例子，都会发现第一点第二点不是问题，第三点属于数据访问权限控制，可以写自己的Principal，在Principal中存一个地区信息比如areaId，然后取数据的时候带着这个areaId的条件访问好了。

页面模板上的if else没法避免，这是必须写的，Shiro有自己的jsp tag。
api的权限控制可以通过shiro的配置定义过滤链，一般shiro自己的过滤器够用了，接口权限通过过滤器来做的，那么不会和你的业务代码有耦合，改配置的事。
但是动态权限这种要按地区做数据访问的可能会有业务代码的耦合，我觉得这已经不是role based了，而本来就属于业务需求的一部分。

[BoiledEgg]

‘无法用到jsp标签控制渲染内容’ 什么意思？你们没有后台渲染的过程，模板就是直接取静态文件？
这样完全没有后台模板渲染，全在前台渲染的话会暴露权限外的接口的吧？我觉得这样不好，即使你现在保证说这个接口别人知道了也访问不了，但是隐藏入口总好过暴露出来。

[LuoboTixS]

Structure Breakdown:

1. authorization object <=> exact action + determination logic
2. authorization profile consists of authorization objects
3. assign authorization profile to user group
4. specific user belongs to designated user group and inherits the assigned authorization profile

In case cross-group authorization needed, assign additional authorization profile to specific user

[kimmykuang]

我觉得RBAC完全可以做到啊

[netlichun]

楼主讲的这个需求很典型，正好我之前的项目也遇到过，下面说一下我的解决思路：

从大的方面来说，可以把权限分成两类：一类与功能有关，我们可以称之为“操作权限”，你所讲的1 和 2 都可以归为这一类；另一类与数据有关，我们可以称之为“访问权限”，你所讲的某地领导只能看到某地信息，就可以归为这一类。

这两个权限分类，可以分别做具体设计，比如对操作权限可以树状分层（例如：模块 -> 页面 -> 按钮），这就解决了不同粒度的管理问题，然后操作权限是直接赋给用户，还是通过角色间接赋给用户，针对不同的开发环境、用户需求和软件规模，都可以斟酌设计，不再赘述。

对于访问权限，根据具体业务需求，也需要考虑合适的实现方式，针对你的这个需求（不过你的描述有点模糊，“如果有同事和自己一组，那么只能修改、查看供应信息，不能删除”，这句话我没搞懂什么意思。），可以采用匹配模型方式。

简单的匹配模型，就是判断字段是否相等，比如匹配地域、团队分组等字段，详细来说就是用户有一个地域字段，信息也有一个地域字段，这样就可以控制用户看到的信息范围了。

复杂一点的匹配模型，可以这样：用户与信息，都有一个访问范围字段，该访问范围字段是多选项，可以通过两个字段的选项是否用重叠来判断用户对信息的访问权限。

以上。表达能力有限，回答的有些散乱，希望能够对楼主有些帮助。

[lutasa43210]

@netlichun 赞 感谢思路分享 很有启发

[BeatenMo]

rbac不行吗？

[armoni]

看到北邮人论坛-05年的一个讨论http://bbs.byr.cn/#!article/SoftDesign/333
1.和@netllchun的看法类似，1、2能用rbac做，3必须嵌入业务逻辑
2.@BolledEgg， @BeatenMo 之前对RBAC的理解仅限于对菜单进行控制，现在项目要web和移动端，要控制资源、页面控件和API有点乱
谢谢各位提供思路。
先用shiro做个demo试试，到时候再来回复此帖。

[armoni]

@BoiledEgg 其实现在很难隐藏接口，web部分可以渲染，但是移动端必须得用API，一个fiddle就全出来了

[hsluoyz]

可以看一下 Casbin： https://github.com/casbin/casbin