电商课题：RBAC权限控制
- - 博客园_旁观者RBAC：Role-Based Access Control，基于角色的访问控制. 问题一： 对某一个用户只授予一些特殊的权限. 描述：既不希望扩大某一个角色的权限，也不希望因此创建出很多零碎的、只为一个用户而存在的角色. 描述：B/S 下，菜单、页面、页面元素、dataset的列，这些层层权限判断过于复杂，容易造成系统访问非常缓慢.
电商课题：RBAC权限控制
标签：
电商
rbac
控制
| 发表时间：2012-11-17 22:47 | 作者：旁观者
出处：http://www.cnblogs.com/zhengyun_ustc/
名词解释：
RBAC：Role-Based Access Control，基于角色的访问控制
关键词：
RBAC，Java Shiro，Spring Security，
一. RBAC 要解决的 常见问题
问题一： 对某一个用户只授予一些特殊的权限
描述：既不希望扩大某一个角色的权限，也不希望因此创建出很多零碎的、只为一个用户而存在的角色。
问题二： 性能问题
描述：B/S 下，菜单、页面、页面元素、dataset的列，这些层层权限判断过于复杂，容易造成系统访问非常缓慢。
问题三： 如何减少 HardCode（硬编码）
描述：
问题四：系统上线后，某个页面增加一个新HTML控件或数据集，这种细粒度权限控制如何以最快速度添加？
描述：对一个 Resource 的 Privilege ，如何快速增加定义？如何快速分配权限？页面如何控制？
问题五：系统上线后，增加一个新细粒度权限控制，运营部门如何最快速度将其应用到已存在角色和帐号上？
描述：对于系统中已存在的成百上千角色、成千上万帐号甚至于无数用户组，一个运营部门的管理人员，如何能以最小代价，通过界面，将此权限分配出去。
二. 一个在权限逻辑和业务逻辑之间做切割的设计原则
2.1.细粒度是否算权限系统的范畴
先解释两个概念：
- 粗粒度：表示类别级。即仅考虑对象的类别，不考虑对象的某个特定实例。譬如，用户管理中，增删改查，对所有的用户都一视同仁，并不区分操作的具体对象实例。
- 细粒度：表示实例级。即需要考虑具体对象的实例，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。譬如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。
权限逻辑配合业务逻辑。
譬如，需求方给出了一个场景：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”，那么这 既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。
如果认为这是一个业务逻辑问题，那么设计权限系统时就不需要过多考虑这种场景。
当然，权限系统也必须能支持这样的控制判断，或者说，权限系统提供足够多但不是完全的控制能力。
此时，设计原则归结为：“ 系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。
这也是复杂问题简单化的一种思路。
这些对具体 Resource Instance 的细粒度权限问题，被留给业务逻辑来解决，这样的考虑基于以下两点：
- 细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现。这样，又引入了 Owner 概念。
- 譬如，如果要求创建者和普通用户看到不同的信息内容，那么资源本身应该有其创建者的信息。如同 Unix 的每一个文件（资源），都定义了对 Owner， Group， All 的不同操作属性。
- 细粒度的权限常常具有相当大的业务逻辑相关性。
- 对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。 相比之下，粗粒度的权限更具通用性，将其实现为一个架构，更有重用价值；而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐，而且不是那么的有必要，用定制的代码来实现就更简洁，更灵活。
当然， 郑昀说，权限系统不可能做成通用，必须就事论事，所以往往在设计时，还是既照顾粗粒度也照顾细粒度。这里只是提一下有这种一刀切的思路。
2.1.数据集的列权限是否算权限系统的范畴
页面需要展示一个数据集（dataset），那么对某些列的展示、可读、可写的控制，是否要放在权限系统中解决？答案是，为了简化，为了避免过度侵入业务逻辑，列权限不在权限系统范畴内。
三. RBAC 是什么
RBAC 认为权限授权实际上是 Who、What、How 的问题，即可简单表述为： 判断“Who 对 What(Which) 进行 How 的操作”的逻辑表达式是否为真。
RBAC 涉及的概念有：
- Who：权限的拥用者或主体（如 User、Group、Role 等）；
- What：权限针对的对象或资源（Resource、Class）；
- How：具体的权限（Privilege）。
- 正向授权在开始时假定主体没有任何权限，然后根据需要授予权限，适合于权限要求严格的系统。
- 负向授权在开始时假定主体有所有权限，然后将某些特殊权限收回。
- Operator：操作。表明对 What 的 How 操作。
- 也就是 Privilege+Resource ；
- 注意，这里的 Resource 仅包括 Resource Type 不表示 Resource Instance；
- 之所以将 What 和 How 绑在一起作为一个 Operator 概念，而不是分开建模再建立关联，这是因为很多的 How 对于某个具体 What 才有意义。譬如，发布操作对新闻对象才有意义，对用户对象则没有意义。
- Role：角色，一定数量的权限的集合。权限分配的单位与载体，目的是隔离 User 与 Privilege 的逻辑关系；
- Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User 与 Group 是多对多的关系。Group 可以层次化，以满足不同层级权限控制的要求。
- Session： 会话是用户与激活的角色集合之间的映射。每个 Session 和单个的 User 关联，每个 User 可以关联到一或多个 Session 。
RBAC 支持三个安全原则：
- 最小权限原则（即细粒度控制原则）：
- RBAC 可将其角色配置成其完成任务所需要的最小权限集；
- 责任分离原则
- 通过调用相互独立互斥的角色来共同完成敏感的任务而体现，如要求一个计帐员和财务管理员一起参与同一个过帐；
- 数据抽象原则
- 通过权限的抽象来体现，如财务操作用借款、存款等抽象权限。
四. 标准 RBAC 模型
NIST （美国国家标准与技术研究院）标准 RBAC 模型由4个部件模型组成，分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。
RBAC0 模型如图1所示：
 |
| 图1 RBAC 0 模型 |
RBAC0 定义了能构成一个 RBAC 控制系统的最小的元素集合：
- RBAC 定义了 五个基本数据元素：
- 用户 users(USERS)
- 角色 roles(ROLES)
- 目标 objects(OBS)
- 操作 operations(OPS)
- 许可权 permissions(PRMS)
- RBAC0 业务规则有：
- 一个用户可以对应多个角色，一个角色也可以分配给多个用户；
- 一个角色可以有多个许可权，一种许可权则只与一个角色对应；
- 用户可以发起会话，会话中可以激活多个角色来获取许可权；
- 用户、角色、许可权全部由超级管理员创建与指派；
- 一个用户拥有多个角色时，高优先级的角色权限覆盖低优先级的角色权限。
RBAC1（引入角色继承关系）、RBAC2（引入责任分离关系）、RBAC3 （角色继承+责任分离）都是先后在 RBAC0 上的扩展。
五. RBAC 核心对象模型
授权模型：用户-角色-权限
核心动作：
- 创造权限
- 分配权限
- 使用权限
核心动作的主要参与者：
- Creator 创造权限：这里完成的是 Privilege 与 Resource 的对象声明；
- Administrator 分配权限：把 Privilege 与 Resource Instance 真正关联到一起，产生了 Operator （Privilege Instance）。Administrator 利用 Operator 这个基本元素，来创造他理想中的权限模型，如创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等；
- User 使用权限
参考资料：
1）iteye编辑总结， 权限控制讨论；
3） jackyz@jdon，2002， 关于权限系统的设计
相关 [电商 rbac 控制] 推荐：
RBAC综述(转)
- - 企业架构 - ITeye博客摘要 基于角色的访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注. 在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限. 在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色.
干货：品牌电商如何控制成本
- - 互联网分析成本是所有公司老板都非常关心的因素，毕竟利润=收入 – 成本. 当然，就算有利润也不一定能赚钱，因为还有各种各样的税，咱们就不谈了. 相 信很多电商朋友跟我们一样，对财务都不太懂，只能慢慢摸索，想了解如何计算电商运营成本的一些知识，发现网络上基本找不到. 现在很多小公司的计算方法很粗 糙，而大公司虽然会有自己很专业的财务团队，但算来算去很多老板也看不懂.
控制SKU数量，融入社交概念，生鲜团购电商拼好货是怎么火起来的？
- - 创业邦国内各种电商不少，但大多品类繁杂，消费者在购物上的时间成本较高，因此，拼好货想做一个更像美国精选超市Costco一样的电商，能够持续为对生活品质有要求的人提供优质优价的货品，控制sku数量，保证产品质量，并将商品毛利率控制在5 %. 而水果高频，又是刚需，因此成了拼好货最先切入的品类. 有趣的是，在拼好货创始人黄铮还没有完全想清晰该怎么走时，就在一天之内获得了高榕资本和IDG的投资.
Nginx带宽控制
- - 火丁笔记有个老项目，通过 Squid 提供文件下载功能，利用 delay_parameters 实现带宽控制，问题是我玩不转 Squid，于是盘算着是不是能在 Nginx 里找到类似的功能. 好消息是 Nginx 提供了 limit_rate 和 limit_rate_after，举个例子来说明一下：.
电商之城
- 可可 - 《商业价值》杂志原产地效应正在点亮越来越多的电商之城，这代表着电子商务正在逐步回归“商务”的本质. 从机场拿一份免费的手绘地图，和着有点潮湿的空气，足够开启对厦门这座海滨城市的造访. 从市中心到达位于厦门东北方向的软件园二期，只用了不到20分钟. 对于一个习惯了北京的拥堵和密集的人来说，一座被出租车师傅将半小时车程定义为“还挺远”的城市，从一开始就带给人惊喜.
Firebug控制台详解
- boho - 阮一峰的网络日志Firebug是网页开发的利器，能够极大地提升工作效率. 我曾经翻译过一篇《Firebug入门指南》，介绍了一些基本用法. 控制台（Console）是Firebug的第一个面板，也是最重要的面板，主要作用是显示网页加载过程中产生各类信息. Firebug内置一个console对象，提供5种方法，用来显示信息.
HBase 之访问控制
- gengmao - Trend Micro CDC SPN Team构建和运维HBase集群是一个非常有挑战性的工作. HBase凭借其在海量数据的良好的扩展性和高效的读写能力，受到越来越多公司的重视. 在公司里，HBase越来越受欢迎. 希望通过HBase读写数据的产品越来越多，在兴奋之余，头疼的问题也来了. 毕竟，作为线上的产品，我们不希望过多人随意的访问，会照成很多潜在的风险，比如误删，误操作.
当算法控制世界
- 芸窗 - SolidotBBC的报导称，看不见的算法正在控制我们在数字世界里的互动，而糟糕的是我们正失去对这些代码的控制. 从图书和电影推荐算法，到Facebook的朋友推荐和图像标记服务，到搜索引擎，算法已经渗透到了我们生活之中. 在上月的TED大会上，算法专家Kevin Slavin描述了算法是如何塑造我们的世界，他发出警告，我们生的活正日益为算法所控制，我们正在编写我们无法理解的，可能不受控制的代码.
高并发库存控制
- - 企业架构 - ITeye博客1、在秒杀的情况下，肯定不能如此高频率的去读写数据库，会严重造成性能问题的. 必须使用缓存，将需要秒杀的商品放入缓存中，并使用锁来处理其并发情况. 当接到用户秒杀提交订单的情况下，先将商品数量递减（加锁/解锁）后再进行其他方面的处理，处理失败在将数据递增1（加锁/解锁），否则表示交易成功. 当商品数量递减到0时，表示商品秒杀完毕，拒绝其他用户的请求.