0. 前言一年前我负责的一个项目中需要权限管理。当时凭着自己的逻辑设计出了一套权限管理模型基本原理与RBAC非常相似只是过于简陋。当时google了一些权限管理的资料从中了解到早就有了RBAC这个东西。可惜一直没狠下心来学习。更详细的RBAC模型非常复杂。本文只做了一些基础的理论性概述。本文资料完全来自互联网。1. 权限系统与RBAC模型概述RBACRole-Based Access Control 基于角色的访问控制。在20世纪90年代期间大量的专家学者和专门研究单位对RBAC的概念进行了深入研究先后提出了许多类型的RBAC模型其中以美国George Mason大学信息安全技术实验室LIST提出的RBAC96模型最具有系统性得到普遍的公认。RBAC认为权限的过程可以抽象概括为判断【Who是否可以对What进行How的访问操作Operator】这个逻辑表达式的值是否为True的求解过程。即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。RBAC支持公认的安全原则最小特权原则、责任分离原则和数据抽象原则。最小特权原则得到支持是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。责任分离原则的实现是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现例如在清查账目时只需要设置财务管理员和会计两个角色参加就可以了。数据抽象是借助于抽象许可权这样的概念实现的如在账目管理活动中可以使用信用、借方等抽象许可权而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则安全管理员可以允许配置RBAC模型使它不支持这些原则。因此RBAC支持数据抽象的程度与RBAC模型的实现细节有关。RBAC96是一个模型族其中包括RBAC0~RBAC3四个概念性模型。1、基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。2、RBAC1和RBAC2两者都包含RBAC0但各自都增加了独立的特点它们被称为高级模型。RBAC1中增加了角色分级的概念一个角色可以从另一个角色继承许可权。RBAC2中增加了一些限制强调在RBAC的不同组件中在配置方面的一些限制。3、RBAC3称为统一模型它包含了RBAC1和RBAC2利用传递性也把RBAC0包括在内。这些模型构成了RBAC96模型族。RBAC模型简述RBAC0的模型中包括用户U、角色R和许可权P等3类实体集合。RABC0权限管理的核心部分其他的版本都是建立在0的基础上的看一下类图RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素此模型指明用户、角色、访问权限和会话之间的关系。每个角色至少具备一个权限每个用户至少扮演一个角色可以对两个完全不同的角色分配完全相同的访问权限会话由用户控制一个用户可以创建会话并激活多个用户角色从而获取相应的访问权限用户可以在会话中更改激活角色并且用户可以主动结束一个会话。用户和角色是多对多的关系表示一个用户在不同的场景下可以拥有不同的角色。例如项目经理也可以是项目架构师等当然了一个角色可以给多个用户例如一个项目中有多个组长多个组员等。这里需要提出的是将用户和许可进行分离是彼此相互独立使权限的授权认证更加灵活。角色和许可权限是多对多的关系表示角色可以拥有多分权利同一个权利可以授给多个角色都是非常容易理解的想想现实生活中当官的级别不同的权限的情景其实这个模型就是对权限这方面的一个抽象联系生活理解就非常容易了。RBAC1基于RBAC0模型引入角色间的继承关系即角色上有了上下级的区别角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构实现角色间的单继承。这种模型合适于角色之间的层次明确包含明确。RBAC2基于RBAC0模型的基础上进行了角色的访问控制。RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时或角色被赋予用户时以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可此约束有多种。互斥角色 同一用户只能分配到一组互斥角色集合中至多一个角色支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色不能同时获得两个角色的使用权。常举的例子在审计活动中一个角色不能同时被指派给会计角色和审计员角色。基数约束 一个角色被分配的用户数量受限一个用户可拥有的角色数目受限同样一个角色对应的访问权限数目也应受限以控制高级权限在系统中的分配。例如公司的领导人有限的先决条件角色 可以分配角色给用户仅当该用户已经是另一角色的成员对应的可以分配访问权限给角色仅当该角色已经拥有另一种访问权限。指要想获得较高的权限要首先拥有低一级的权限。就像我们生活中国家主席是从副主席中选举的一样。运行时互斥 例如允许一个用户具有两个角色的成员资格但在运行中不可同时激活这两个角色。RBAC3也就是最全面级的权限管理它是基于RBAC0的基础上将RBAC1和RBAC2进行整合了最前面也最复杂的综上为权限管理模型的相关介绍其实在任何系统中都会涉及到权限管理的模块无论复杂简单我们都可以通过以RBAC模型为基础进行相关灵活运用来解决我们的问题。RBAC的优缺点RBAC模型没有提供操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作次序的实体系统。例如在购物控制系统中要求系统对购买步骤的控制在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到模型2. 实用的RBAC模型的数据库建模以下模型均来自于互联网1、扩展RBAC用户角色权限设计方案RBACRole-Based Access Control基于角色的访问控制就是用户通过角色与权限进行关联。简单地说一个用户拥有若干角色每一个角色拥有若干权限。这样就构造成“用户-角色-权限”的授权模型。在这种模型中用户与角色之间角色与权限之间一般者是多对多的关系。如下图角色是什么可以理解为一定数量的权限的集合权限的载体。例如一个论坛系统“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等这些是权限。要给某个用户授予这些权限不需要直接将权限授予用户可将“版主”这个角色赋予该用户。当用户的数量非常大时要给系统每个用户逐一授权授角色是件非常烦琐的事情。这时就需要给用户分组每个用户组内有多个用户。除了可给用户授权外还可以给用户组授权。这样一来用户拥有的所有权限就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。下图为用户组、用户与角色三者的关联关系在应用系统中权限表现成什么对功能模块的操作对上传文件的删改菜单的访问甚至页面上某个按钮、某个图片的可见性控制都可属于权限的范畴。有些权限设计会把功能操作作为一类而把文件、菜单、页面元素等作为另一类这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时可把功能操作和资源统一管理也就是都直接与权限表进行关联这样可能更具便捷性和易扩展性。见下图请留意权限表中有一列“权限类型”我们根据它的取值来区分是哪一类权限如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。这样设计的好处有二。其一不需要区分哪些是权限操作哪些是资源实际上有时候也不好区分如菜单把它理解为资源呢还是功能模块权限呢。其二方便扩展当系统要对新的东西进行权限控制时我只需要建立一个新的关联表“权限XX关联表”并确定这类权限的权限类型字符串。这里要注意的是权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。文件、页面权限点、功能操作等同理。也就是每添加一个菜单就得同时往这三个表中各插入一条记录。这样可以不需要权限菜单关联表让权限表与菜单表直接关联此时须在权限表中新增一列用来保存菜单的ID权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。到这里RBAC权限模型的扩展模型的完整设计图如下随着系统的日益庞大为了方便管理可引入角色组对角色进行分类管理跟用户组不同角色组不参与授权。例如某电网系统的权限管理模块中角色就是挂在区局下而区局在这里可当作角色组它不参于权限分配。另外为方便上面各主表自身的管理与查找可采用树型结构如菜单树、功能树等当然这些可不需要参于权限分配。2、百度百科所示的模型3、本文参考文献中的一种设计辨析角色与用户组有何区别两者的主要差别是用户组是用户的集合但不是许可权的集合而角色却同时具有用户集合和许可权集合的概念角色的作用把这两个集合联系在一起的中间媒介。在一个系统中如果用户组的许可权和成员仅可以被系统安全员修改的话在这种机制下用户组的机制是非常接近于角色的概念的。角色也可以在用户组的基础上实现这有利于保持原有系统中的控制关系。在这种情况下角色相当于一个策略部件与用户组的授权及责任关系相联系而用户组是实现角色的机制因此两者之间是策略与实现机制之间的关系。3. ACL模型访问控制列表是前几年盛行的一种权限设计它的核心在于用户直接和权限挂钩。RBAC的核心是用户只和角色关联而角色代表对了权限这样设计的优势在于使得对用户而言只需角色即可以而某角色可以拥有各种各样的权限并可继承。ACL和RBAC相比缺点在于由于用户和权限直接挂钩导致在授予时的复杂性虽然可以利用组来简化这个复杂性但仍然会导致系统不好理解而且在取出判断用户是否有该权限时比较的困难一定程度上影响了效率。4. 基于RBAC模型的权限验证框架与应用Apache Shirospring SecuritySELinuxRBAC参考文献http://csrc.nist.gov/groups/SNS/rbac/index.htmlRole Based Access Control | CSRC原文地址https://blog.csdn.net/yangwenxue_admin/article/details/73936803