RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系。(如下图)
角色是什么?可以理解为一定数量的权限的集合,权限的载体。例如:一个论坛系统,“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等,这些是权限。要给某个用户授予这些权限,不需要直接将权限授予用户,可将“版主”这个角色赋予该用户。
当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,每个用户组内有多个用户。除了可给用户授权外,还可以给用户组授权。这样一来,用户拥有的所有权限,就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色三者的关联关系)
在应用系统中,权限表现成什么?对功能模块的操作,对上传文件的删改,菜单的访问,甚至页面上某个按钮、某个图片的可见性控制,都可属于权限的范畴。有些权限设计,会把功能操作作为一类,而把文件、菜单、页面元素等作为另一类,这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时,可把功能操作和资源统一管理,也就是都直接与权限表进行关联,这样可能更具便捷性和易扩展性。(见下图)
请留意权限表中有一列“权限类型”,我们根据它的取值来区分是哪一类权限,如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。
这样设计的好处有二。其一,不需要区分哪些是权限操作,哪些是资源,(实际上,有时候也不好区分,如菜单,把它理解为资源呢还是功能模块权限呢?)。其二,方便扩展,当系统要对新的东西进行权限控制时,我只需要建立一个新的关联表“权限XX关联表”,并确定这类权限的权限类型字符串。
这里要注意的是,权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。(文件、页面权限点、功能操作等同理)。也就是每添加一个菜单,就得同时往这三个表中各插入一条记录。这样,可以不需要权限菜单关联表,让权限表与菜单表直接关联,此时,须在权限表中新增一列用来保存菜单的ID,权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。
到这里,RBAC权限模型的扩展模型的完整设计图如下:
随着系统的日益庞大,为了方便管理,可引入角色组对角色进行分类管理,跟用户组不同,角色组不参与授权。例如:某电网系统的权限管理模块中,角色就是挂在区局下,而区局在这里可当作角色组,它不参于权限分配。另外,为方便上面各主表自身的管理与查找,可采用树型结构,如菜单树、功能树等,当然这些可不需要参于权限分配。
另外一篇
- 粗粒度:表示类别级。即仅考虑对象的类别,不考虑对象的某个特定实例。譬如,用户管理中,增删改查,对所有的用户都一视同仁,并不区分操作的具体对象实例。
- 细粒度:表示实例级。即需要考虑具体对象的实例,当然,细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。譬如,合同管理中,列表、删除,需要区分该合同实例是否为当前用户所创建。
- 细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现。这样,又引入了 Owner 概念。
- 譬如,如果要求创建者和普通用户看到不同的信息内容,那么资源本身应该有其创建者的信息。如同 Unix 的每一个文件(资源),都定义了对 Owner, Group, All 的不同操作属性。
- 细粒度的权限常常具有相当大的业务逻辑相关性。
- 对不同的业务逻辑,常常意味着完全不同的权限判定原则和策略。相比之下,粗粒度的权限更具通用性,将其实现为一个架构,更有重用价值;而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐,而且不是那么的有必要,用定制的代码来实现就更简洁,更灵活。
- 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 可将其角色配置成其完成任务所需要的最小权限集;
- 责任分离原则
- 通过调用相互独立互斥的角色来共同完成敏感的任务而体现,如要求一个计帐员和财务管理员一起参与同一个过帐;
- 数据抽象原则
- 通过权限的抽象来体现,如财务操作用借款、存款等抽象权限。
|
图1 RBAC 0 模型
|
- RBAC 定义了 五个基本数据元素:
- 用户 users(USERS)
- 角色 roles(ROLES)
- 目标 objects(OBS)
- 操作 operations(OPS)
- 许可权 permissions(PRMS)
- RBAC0 业务规则有:
- 一个用户可以对应多个角色,一个角色也可以分配给多个用户;
- 一个角色可以有多个许可权,一种许可权则只与一个角色对应;
- 用户可以发起会话,会话中可以激活多个角色来获取许可权;
- 用户、角色、许可权全部由超级管理员创建与指派;
- 一个用户拥有多个角色时,高优先级的角色权限覆盖低优先级的角色权限。
- 创造权限
- 分配权限
- 使用权限
- Creator 创造权限:这里完成的是 Privilege 与 Resource 的对象声明;
- Administrator 分配权限:把 Privilege 与 Resource Instance 真正关联到一起,产生了 Operator (Privilege Instance)。Administrator 利用 Operator 这个基本元素,来创造他理想中的权限模型,如创建角色,创建用户组,给用户组分配用户,将用户组与角色关联等;
- User 使用权限