文档章节

电商课题:RBAC权限控制

旁观者-郑昀
 旁观者-郑昀
发布于 2012/11/24 14:05
字数 2246
阅读 718
收藏 18
 
名词解释:
RBAC:Role-Based Access Control,基于角色的访问控制
 
关键词:
RBAC,Java Shiro,Spring Security,
 
一. RBAC 要解决的常见问题
问题一: 对某一个用户只授予一些特殊的权限
描述:既不希望扩大某一个角色的权限,也不希望因此创建出很多零碎的、只为一个用户而存在的角色。
 
问题二: 性能问题
描述:B/S 下,菜单、页面、页面元素、dataset的列,这些层层权限判断过于复杂,容易造成系统访问非常缓慢。
 
问题三: 如何减少 HardCode(硬编码)
描述:
 
问题四:系统上线后,某个页面增加一个新HTML控件或数据集,这种细粒度权限控制如何以最快速度添加?
描述:对一个 Resource 的 Privilege ,如何快速增加定义?如何快速分配权限?页面如何控制?
 
问题五:系统上线后,增加一个新细粒度权限控制,运营部门如何最快速度将其应用到已存在角色和帐号上?
描述:对于系统中已存在的成百上千角色、成千上万帐号甚至于无数用户组,一个运营部门的管理人员,如何能以最小代价,通过界面,将此权限分配出去。
 
二. 一个在权限逻辑和业务逻辑之间做切割的设计原则
2.1.细粒度是否算权限系统的范畴
先解释两个概念:
  • 粗粒度:表示类别级。即仅考虑对象的类别,不考虑对象的某个特定实例。譬如,用户管理中,增删改查,对所有的用户都一视同仁,并不区分操作的具体对象实例。
  • 细粒度:表示实例级。即需要考虑具体对象的实例,当然,细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。譬如,合同管理中,列表、删除,需要区分该合同实例是否为当前用户所创建。
权限逻辑配合业务逻辑。
譬如,需求方给出了一个场景:“合同资源只能被它的创建者删除,与创建者同组的用户可以修改,所有的用户能够浏览”,那么这 既可以认为是一个细粒度的权限问题,也可以认为是一个业务逻辑问题
如果认为这是一个业务逻辑问题,那么设计权限系统时就不需要过多考虑这种场景。
当然,权限系统也必须能支持这样的控制判断,或者说,权限系统提供足够多但不是完全的控制能力。
此时,设计原则归结为:“ 系统只提供粗粒度的权限,细粒度的权限被认为是业务逻辑的职责”。
这也是复杂问题简单化的一种思路。
 
这些对具体 Resource Instance 的细粒度权限问题,被留给业务逻辑来解决,这样的考虑基于以下两点:
  1. 细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现。这样,又引入了 Owner 概念。
    • 譬如,如果要求创建者和普通用户看到不同的信息内容,那么资源本身应该有其创建者的信息。如同 Unix 的每一个文件(资源),都定义了对 Owner, Group, All 的不同操作属性。
  2. 细粒度的权限常常具有相当大的业务逻辑相关性。
    • 对不同的业务逻辑,常常意味着完全不同的权限判定原则和策略。相比之下,粗粒度的权限更具通用性,将其实现为一个架构,更有重用价值;而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐,而且不是那么的有必要,用定制的代码来实现就更简洁,更灵活。
当然, 郑昀说,权限系统不可能做成通用,必须就事论事,所以往往在设计时,还是既照顾粗粒度也照顾细粒度。这里只是提一下有这种一刀切的思路。
 
2.1.数据集的列权限是否算权限系统的范畴
页面需要展示一个数据集(dataset),那么对某些列的展示、可读、可写的控制,是否要放在权限系统中解决?
答案是,为了简化,为了避免过度侵入业务逻辑,列权限不在权限系统范畴内。
 
三. RBAC 是什么
RBAC 认为权限授权实际上是  WhoWhatHow 的问题,即可简单表述为: 判断“Who 对 What(Which) 进行 How 的操作”的逻辑表达式是否为真
 
RBAC 涉及的概念有:
  • Who:权限的拥用者或主体(如 UserGroupRole 等);
  • What:权限针对的对象或资源(ResourceClass);
  • 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 支持三个安全原则:
  1. 最小权限原则(即细粒度控制原则):
    • RBAC 可将其角色配置成其完成任务所需要的最小权限集;
  2. 责任分离原则
    • 通过调用相互独立互斥的角色来共同完成敏感的任务而体现,如要求一个计帐员和财务管理员一起参与同一个过帐;
  3. 数据抽象原则
    • 通过权限的抽象来体现,如财务操作用借款、存款等抽象权限。
 
四. 标准 RBAC 模型
NIST (美国国家标准与技术研究院)标准 RBAC 模型由4个部件模型组成,分别是基本模型RBAC0Core RBAC)、角色分级模型RBAC1Hierarchal RBAC)、角色限制模型RBAC2Constraint RBAC)和统一模型RBAC3Combines RBAC)。
RBAC0 模型如图1所示:
http://images.cnblogs.com/cnblogs_com/zhengyun_ustc/255879/o_clipboard39.png
图1 RBAC 0 模型
RBAC0 定义了能构成一个 RBAC 控制系统的最小的元素集合:
  • RBAC 定义了 五个基本数据元素:
    1. 用户 users(USERS)
    2. 角色 roles(ROLES)
    3. 目标 objects(OBS)
    4. 操作 operations(OPS)
    5. 许可权 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, 关于权限系统的设计
分类:  电商课题

© 著作权归作者所有

旁观者-郑昀
粉丝 100
博文 77
码字总数 162700
作品 0
朝阳
私信 提问
关于 Multiget hole:spymemcached对此的实现方法

火丁说: 『 Multiget的无底洞问题 Facebook在Memcached的实际应用中,发现了Multiget无底洞问 题,具体表现为:出于效率的考虑,很多Memcached应用都已Multiget操作为主,随着访问量的增加,...

旁观者-郑昀
2013/02/08
127
0
spymemcached :某个mc节点操作连续超时超过998次就 Auto-Reconne...

spymemcached 中,一个 mc client 与某一个 mc node 之间已建立的 connection 上, 如果执行操作屡屡超时(net.spy.memcached.OperationTimeoutException), 那么,有一个计数器专门记录超时...

旁观者-郑昀
2013/02/08
162
0
spymemcached 的 useNagle 问题与 TCP/IP延迟发送数据

先说一下结论。 如果你没有特意在 spymemcached 的 client bean definition 里配置 useNagleAlgorithm 属性为 True, 那么默认 spymemcached 是不启用 Nagle 算法的。 所以默认情况下不会引发...

旁观者-郑昀
2013/02/08
167
0
SaaS后台经验分享:如何设计权限管理

权限管理的作用 SaaS后台系统中,数据具有敏感性,由于工作职责不同,所以用户拥有的权限也不同。因此,系统需要给用户分配权限,使得用户在规定范围内使用系统。 RBAC模型介绍 本文介绍的R...

PMhome123
2018/12/21
0
0
基于RBAC模型的权限系统设计(Github开源项目)

计划在Team的Github开源项目里加入权限控制的业务功能。从而实现权限控制。在很多管理系统里都是有权限管理这些通用模块的,当然在企业项目里,权限控制是很繁杂的。 Team的Github开源项目链...

Javahih
2017/12/25
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Kafka实战(五) - 核心API及适用场景全面解析

1 四个核心API ● Producer API 允许一个应用程序发布一串流式的数据到一个或者多个Kafka topic。 ● Consumer API 允许一个应用程序订阅一个或多个topic ,并且对发布给他们的流式数据进行处...

JavaEdge
今天
11
0
实现线程的第三种方式——Callable & Future

Callable Runnable 封装一个异步运行的任务, 可以把它想象成为一个没有参数和返回值的异步方 法。Callable 与 Runnable 类似, 但是有返回值。Callable 接口是一个参数化的类型, 只有一 个...

ytuan996
今天
12
0
OSChina 周六乱弹 —— 不要摁F了!

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @巴拉迪维 : 朴树写的词曲都给人一种莫名的失落感,不过这首歌他自己却没有唱,换成赵传这种高音阶嘶喊的确很好,低沉但却有力,老男人的呐喊...

小小编辑
今天
22
0
Android Binder机制 - interface_cast和asBinder讲解

研究Android底层代码时,尤其是Binder跨进程通信时,经常会发现interface_cast和asBinder,很容易被这两个函数绕晕,下面来讲解一下: interface_cast 下面根据下述ICameraClient例子进行分析...

天王盖地虎626
昨天
13
0
计算机实现原理专题--存储器的实现(二)

计算机实现原理专题--存储器的实现(一)中描述了一种可以记住输入端变化的装置。现需要对其功能进行扩充,我们将上面的开关定义为置位,下面的开关定义为复位,然后需要增加一个保持位,当保...

FAT_mt
昨天
9
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部