基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展 - 高海东 - 博客园
1&RBAC模型 &&&&&& 访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，从而使计算机系统在合法范围内使用；决定用户能做什么，也决定代表一定用户利益的程序能做什么[1]。&&&&&& &企业环境中的访问控制策略一般有三种：自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法（RBAC）。其中，自主式太弱，强制式太强，二者工作量大，不便于管理[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销；2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。 &&&&&& NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。&&&&&&&& a. RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。 &&&&&&&& b. RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。 &&&&&&& c. RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。 &&&&& & d. RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。
&2核心对象模型设计
&&&&& 根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型.对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（Access Mode）、操作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：
&&&&&& a .控制对象：是系统所要保护的资源（Resource），可以被访问的对象。资源的定义需要注意以下两个问题： &&&&&& 1.资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。 &&&&&& 2.这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑： &&&&&&& 一方面，资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。 例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操作，可以修改属于自己管辖的信息内容。 &&&&&&& 另一方面，资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。&&&&&&& b.权限：对受保护的资源操作的访问许可(Access Permission)，是绑定在特定的资源实例上的。对应地，访问策略（Access Strategy）和资源类别相关，不同的资源类别可能采用不同的访问模式（Access Mode）。例如，页面具有能打开、不能打开的访问模式，按钮具有可用、不可用的访问模式，文本编辑框具有可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如，某个数据集的可修改访问模式就包含了可查询访问模式。 &&&&&&& c.用户：是权限的拥有者或主体。用户和权限实现分离，通过授权管理进行绑定。 &&&&&&& d.用户组：一组用户的集合。在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。&&&&&&&&&e.角色：权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。 &&&&&&& f.操作：完成资源的类别和访问策略之间的绑定。 &&&&&&& g.分配角色权限PA：实现操作和角色之间的关联关系映射。 &&&&&&& h.分配用户角色UA：实现用户和角色之间的关联关系映射。
&该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于操作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。数据模型图如下：
&希望各位多提意见 ,再完善RBAC权限模型的运用
RBAC权限模型的运用
&&&&&&角色访问控制（RBAC）引入了Role的概念,目的是为了隔离User(即动作主体，Subject)与Privilege(权限，表示对Resource的一个操作，即Operation+Resource)。
Role作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。例如，对于新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。基于角色的访问控制方法（RBAC）的显著的两大特征是：1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
&&&&&&&&在我们系统中存在着5种角色需要对不同的内容进行访问。
1.1&&确定角色需要操作的对象
1.1.1 以数据库中的表作为资源
在本系统中可以存在两种方案来定义角色需要操作的对象，一种方案是角色直接与数库
中的表相关联，也就是说建立一张角色与表的关系表就可以放映出这个关系，但是这样设计有一个地方不好控制，系统完成后是以一个一个页面的形式存在于客户面前，而每一个页面里面所表现的内容难道只和数据库中的一张表有关系？如果存在和多张表的关系时候，那就得首先判断某特定用户属于的角色对这些表的所有权限之后再处理具体的表示层；这种做法需要请求一个页面的时候进行比较多的判断，相当于在角色页面中又增加了一个数据库，即为角色，数据库，页面之间的关系，在做一个对数据库操作比较少的系统时这么做显然是很麻烦的。
1.1.2 以页面作为资源
本系统另外一种定义资源的方式是以页面做为资源，当页面做为资源的时候，我们可以在一开就用一个asp.net内置的对象session来存储角色，然后再用户要请求该页面的时候用这个session来查数据库中的角色权限表，来判断该角色是否对该页面有各种操作的权限，当然某一个用户可能有好几个角色，那只需要多生成几个session来存储角色。这样做的好处是，在用户请求页面的时候判断比较容易。
1.1.3资源选择总结
以上两种方案我选择的是以页面做为资源，主要是该系统对于数据库的操作不会像HIS系统中那样对于数据库的操作那样多。
1.2操作的描述
操作作为权限的核心之一，通常情况下包括了增删改查四种操作，关键的问题就在于如何在数据库中放映出这四种操作，这里仍然有两种方案。第一可以将这四种操作分别作为四个字段，用一个标志号来表示某主体是否具有某种操作，第二可以将这四个操作放在一个字段中用4位二进制数表示，有某一操作就将具体的二进制数至1。这样做的好处，对于权限的操作看起来清晰明了，而且在具体查询角色权限表的时候也只用去查询一个字段，不用查询4个字段，操作上会减少不少。
1.3对于角色和用户的简单描述
一个系统会有使用它的用户群，这个群里，肯定会有很多具有对这个系统有着同等权力的
用户，于是将这些具有同等权力的用户分进某一个角色里。这样角色的数量肯定会少于用户的数量，于是在以后的对庞大的用户资料进行的维护过程中，可以将维护过程简化为用户角色管理与角色权限管理了。
1.4本系统关于用户权限的基本数据表
经过以上分析，本系统所需要的用户管理模块所需要基本数据表就出来了
1.用户信息表
2.角色信息表
3.用户角色关系表
4.角色权限关系表
5.权限对象说明表
以上的表格中，每张表都会用一个ID号来作为该表的主键，其中用户和角色之间是多对多的关系，角色和权限之间也是多对多的关系。每个表中具体字段暂且不表。
1．5分析基本数据表
现在假设一个用户登陆本系统且这个用户为合法用户，那么在他登陆之后就可以根据用户角色表确定该用户的角色（这个角色可以是一个角色，也可以是多个角色）；然后再根据角色权限表可以最终确定该用户对那几个页面有某种具体的组合操作的权力。
狭义上的权限管理有了这5张表明显已经足够了，但是我们系统中存在一个功能树，树的节点是根据特定角色的权限来显示的，也就是说得加一个表功能树数据表，里面将页面对象与树的节点关联起来，当然并不是所有的页面都会与某一个节点对应，也不是所有的节点一定要对应于一个页面，关于这个功能树的表的设计问题在层次数据库设计中本人已经做过分析，这里不再详述。我采用的是父节点加子节点的设计方式。
那么在用户登陆之后查找到了该用户对应的能操作的且存在于功能树结点中的页面，是不是就能够很顺利的显示出树呢？看来似乎还有个小问题需要解决掉！
因为一个用户可能对应于几个角色，好几个角色中显然也有可能存在对同一个页面有相同的操作权力，如果该页面是功能树的一个节点，在用户登陆之后要显示出树就得想办法去掉相同的节点。
在后台代码中我们可以做到这一点，具体做法肯定是把某用户所对应的所有角色的相关页面id号放入一个datatable（ado.net中一个具体对象，相当于一张表格）,然后去掉重复的页面，即id号相同的页面，然后再从功能树数据表中去查找这些页面的父节点生成一颗功能树（具体生成方案两种做法，深度遍历和广度遍历，本章不做讨论）。当然我们完全可以在数据库中在做一张表为角色功能树节点对应表，这样直接通过查找这张表格找出不重复的节点来生成树，这样就减少了很多后台逻辑，带来了很大的方便。
1．6权限管理模块总结
综上所述，本系统的权限管理模块一共有7张数据表：
用户信息表
角色信息表
用户角色关系表
角色权限关系表
权限对象说明表
功能树数据表
7．角色功能树节点对应表
1．7&&&对RBAC模型的分析
&&&&&&NIST（The
National Institute of Standards and
Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core
RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint
RBAC）和统一模型RBAC3（Combines RBAC）。
&&&&&&&上述几节主要是针对RBAC0来谈的，从实际运用和RBAC的其他3个模型我们可以看出，在RBAC模型中对于角色的设计其实是扩展性和灵活性都很强的，本系统中主要是涉及的角色种类并不太多，所以没有考虑角色的继承和限制关系。但是在多觉得功能树节点的重复问题上，明显也可以用角色的继承和限制加以解决，但是由于功能树的节点并不多，所有节点一共也就不到二十个，所以并没有采用RBAC3模型。
&&&&&&当然该模型还有一些可以扩展的地方,在参阅了一些文章后，我觉得以下几点可以更好的扩展RBAC模型。
&&&&&&&1.用户组授权功能。
2.角色类型功能。这个功能并不是很重要，建立一个类型表，每个角色可以归属一个角色类型，便于表达方便，层次清晰，这个功能主要的作用在于表示层的显示上。
3.角色优先功能。可以定义一个优先级别表，给每个角色赋予优先级别，在处理角色的请求时，根据角色的优先级别排入链表里进行处理，链表里的角色请求可以根据优先级别的不同动态调整，系统在处理角色请求时，每次都从队首取一个角色请求，再将队首指针指向下一个角色请求。
4.角色生存周期功能。这个功能可以指定角色的生存时间，时间可以是用户指定的，也可以是根据某个条件来决定的。
5.角色根据责任链动态变更权限功能。在一个责任链里，一个客户程序发出请求，这个请求将沿着责任链进行传递，责任链里的每个结点将依次处理该请求，如果结点不能处理该请求，则将此请求转发到责任链的下一结点上；或者是，责任链中的每一个结点都对该请求进行处理。在处理的过程中，角色的权限将根据需求动态变化。
6.角色根据状态动态变更权限功能。在应用程序中可能存在多种状态，比如在一个字处理程序中，当文件状态是只读时，和文件状态在可读可写时，它的功能是不一样的，那么角色需要根据这种状态的变更而动态变更权限集，以便适应这种应用程序的要求。
&&&&&当然了模型的存在并不意味着任何设计都一定要套用某种模型，只是说这个模型给了我们一些很好的启示和一套已经比较成熟的方法论，毕竟这些只是工程模型并不是数学或者物理定理，我们再设计中实事求是的根据需求，合理的考虑一些扩展性结合这些模型肯定能设计出一套满足我们需要的系统。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。　1、国网河北省电力公司信息通信分公司& 、华北电力大学& 保定& 071003
　　摘要：基于角色的访问控制（Role-Based Access Control）作为传统访问控制模型已得到广泛的认可及应用，本文对传统的RBCA模型进行了优化，并在统一权限管理系统中实现更高效、安全、灵活的权限管理。
　　关键字：RBAC；权限管理；统一权限管理系统
　　随着社会的不断发展，对信息系统授权的方便性、灵活性及安全性提出了更高的要求。在企业级权限管理平台上，需要通过平台对接入系统进行集中授权，对权限控制提出了更高的要求。基于角色的访问控制（Role-Based Access Control）是较为传统并得到广泛认可的访问控制模型，但存在不便于对授权实行层层负责管理的问题。统一权限系统使用的访问权限控制模型正是基于RBCA模型，并在此基础上进行了优化，能够对企业级权限管理平台的大量用户实现层层授权及权限操作数据集控制，方便、灵活、可控。
　　1 RBAC（Role-Based Access Control）模型
　　RBAC模型是由美国国防部（Department of Defense，DoD）资助的研究和开发成果演变而来的，是目前被广泛接受的权限控制模型。标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。RBAC0模型如图1所示：
　　图1 RBAC0模型
　　RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中，包含用户users（USERS）、角色roles（ROLES）、目标objects（OBS）、操作operations（OPS）、许可权permissions（PRMS）五个基本数据元素，权限被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
　　1.1RBAC1 引入角色间的继承关系
　　角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
　　1.2RBAC2 模型中添加了责任分离关系
　　RBAC2 的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
　　1.3RBAC3 包含了RBAC1和RBAC2
　　既提供了角色间的继承关系，又提供了责任分离关系。建立角色定义表。定出当前系统中角色。 因为有继承的问题，所以角色体现出的是一个树形结构。
　　在RBAC体系中，一个用户可以被赋予多个角色，一个角色也可以被赋予多个用户；一个角色可配置多项权限，一个权限也可以赋予多个角色。一个用户可以通过拥有的角色对系统的资源进行特定的操作。
　　2 RBAC模型优化
　　RBAC模型中用户与资源之间的联系通过角色来实现映射，在实际工作中，同一角色对应的不同用户，由于所处的部门不同，职责不同，在同一个系统中的操作对象也不同，需要对角色、权限进行细分。通过对BRAC模型中的角色进行分层，对功能权限的控制粒度进行细化，可以实现对访问权限的更好控制。
　　统一权限系统中，除了用户、角色、权限对象的概念，还引入了业务组织单元、业务组织角色、功能的概念。优化的RBAC模型通过业务组织单元实现对用户的分层；通过角色分组对角色从横向上进行划分；通过功能将权限对象分层，使相似的、组合的权限对象划分在一起，细分粒度介于角色与权限对象之间；通过业务组主角色将组织单元与角色进行管理，并在纵向上对角色进行分层，是权限控制模型的层次更清晰，角色粒度更细，权限控制更方便、灵活、安全。
　　3优化的RBAC在统一权限管理系统的实现
　　3.1基准组织与用户
　　主要包括基准组织单元、用户、岗位三类对象，其详细的描述如下：
　　??用户
　　参与到本企业运营的所有人员，并且一人一账号。角色性质的用户（如：系统管理员）原则上不允许存在。
　　其数据分两部分：
　　A：被人资系统管理的人员数据（全民、集体、农电员工）
　　B：非人资系统管理的人员数据（临时员工、外来的临时人员）
　　??岗位
　　人力资源系统中的岗位。
　　??基准组织单元
　　形成企业主要的行政组织体系的组织单元。
　　3.2组织体系
　　主要由业务组织体系、业务组织单元以及业务组织性质构成，其详细的描述如下：
　　??业务组织体系
　　通常一个企业都会存在不同的业务模块或业务模型，比如：党务管理、工会管理、物资管理、生产管理，通常因为业务运转的需要业务模型会对应一套或多套于基准组织并不完全一至的组织体系。一套业务组织体系可以被多个业务应用系统共享。
　　??业务组织单元
　　业务组织体系中的组织单元，它的作用如下：
　　一：作为该组织下的业务组织角色拥有的功能权限在组织这个维度上的数据权限；
　　二：可以基于业务组织做权限的分级管理，从上图中可以看出业务组织角色是隶属于业务组织的，从而可以很方便的做到本单位或本部门的管理员管理本部门的人和权限，而不需要专门分配专业的权限管理人员
　　三：作为业务应用系统中业务数据之一使用；
　　四：在业务流程中可以以业务组织为基础定义出集团内部相对通用的参与者。
　　这四个作用依据业务应用系统的需要进行取舍，比如：可以把业务组织只当成业务数据之一来使用。
　　??业务组织单元性质
　　用于区分同一组织体系中不同组织单元的管理层次。如：单位、部门、班组等。
　　3.3角色体系
　　主要包括业务角色、业务组织角色、角色分组，其详细描述如下：
　　??业务角色
　　指要完成该业务应用系统的业务需要几种角色来完成，业务角色属于业务应用系统，它与业务组织没有关系。
　　??业务组织角色
　　业务组织角色是具体关联业务角色、业务组织机构、和人的对象，它会继承与之对应的业务角色上的功能权限，同时它也位于某个业务组织下，并且要在业务角色上分配人员。
　　??角色分组
　　用于对角色的分类管理。
　　3.4业务系统功能体系
　　主要包括功能、权限对象、业务系统、数据类型、数据集，其详细描述如下：
　　??功能
　　业务应用系统菜单树，每个菜单下有一组权限对象。
　　??权限对象
　　是一个系统下或一个功能下可进行权限控制的对象。例如：网页上的按钮、文本框等对象。
　　??业务系统
　　对应企业业务中的一个专业或者企业架构中的业务域。
　　??数据类型
　　用于描述一类用于权限控制的数据集合的定义。
　　??数据集
　　描述类数据集的权限控制规则结果定义。
　　3.5授权管理
　　统一权限管理系统包含四方面：基准组织与用户、业务组织体系、角色体系、业务应用系统功能体系。基准组织与用户主要包括：基准组织与用户的分配关系、用户与企业角色的分配关系及企业角色和基准组织之间关系；业务组织体系包含：组织体系和业务组织之间关系、业务组织和业务组织性质之间关系；角色体系主要包括：业务角色与组织角色派生关系、组织角色和业务组织之间分配关系；业务应用系统功能体系包含：业务应用系统和功能之间关系、功能和权限对象之间关联关系。
　　4结束语
　　本文在传统RBAC模型的基础上，根据企业级权限管理平台的使用需求，从横向、纵向上对RBAC中的元素进行了粒度细化，对RBAC模型进行了优化处理。通过实际需求调研，在统一权限管理系统运用了优化的RBAC模型，满足了企业级权限管理平台的权限控制管理的需求。
　　参考文献
　　[1]崔丽娜；郭振斌；龚巧明 基于角色权限管理系统的设计与实现[D]；中国科学院金属研究所；2011年
　　[2]周阳；郭顺生 细粒度RBAC模型在ERP权限管理中的研究与应用[A]；机械制造47卷第542期；2009年10期
　　[3]李漩；刘杰；吴岳辛 一种细粒度下基于角色的访问控制模型[A]；电信科学2008年第8期
　　[4] 张晓韬；何义凯；尹长江 国家电网公司统一权限管理系统概要设计v1.0
您可能感兴趣的其他文章
&&站长推荐
&&期刊推荐
&&原创来稿文章
转寄给朋友
朋友的昵称:
朋友的邮件地址:
您的邮件地址:
写信给编辑
您的邮件地址:我们在做任何一款产品的时候，或多或少都会涉及到用户和权限的问题。譬如，做企业类软件，不同部门、不同职位的人的权限是不同的；做论坛类产品的时候，版主和访客权限也是不一样的；再例如一款产品的收费用户和免费用户权限也是迥然不同的。但在设计产品的用户和权限的关系的时候，很多产品经理可能按照感觉来，在并不清楚用户和权限是否存在优秀的理论模型的时候，就按照自我推理搭建了产品的用户和权限模型。而这种基于感觉和推理的模型肯定是有诸多问题的，譬如写死了关系导致权限不够灵活、考虑不周导致权限覆盖能力弱等等。正如牛顿所言，站在巨人的肩膀上才能看的更远。我们不妨去参照已有的比较成熟的权限模型，如：RBAC（Role-Based Access Control）&&基于角色的访问控制。我搜集了网上很多关于RBAC的资料，大多与如何用数据表实现RBCA相关，并不容易理解。所以，我会以产品经理的角度去解析RBAC模型，并分别举例如何运用这套已得到验证的成熟模型。一、RBAC模型是什么?RBAC是一套成熟的权限模型。在传统权限模型中，我们直接把权限赋予用户。而在RBAC中，增加了&角色&的概念，我们首先把权限赋予角色，再把角色赋予用户。这样，由于增加了角色，授权会更加灵活方便。在RBAC中，根据权限的复杂程度，又可分为RBAC0、RBAC1、RBAC2、RBAC3。其中，RBAC0是基础，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。我们可以根据自家产品权限的复杂程度，选取适合的权限模型。二、基本模型RBAC0解析：RBAC0是基础，很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中，我们把权限赋予角色，再把角色赋予用户。用户和角色，角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。举例：譬如我们做一款企业管理产品，如果按传统权限模型，给每一个用户赋予权限则会非常麻烦，并且做不到批量修改用户权限。这时候，可以抽象出几个角色，譬如销售经理、财务经理、市场经理等，然后把权限分配给这些角色，再把角色赋予用户。这样无论是分配权限还是以后的修改权限，只需要修改用户和角色的关系，或角色和权限的关系即可，更加灵活方便。此外，如果一个用户有多个角色，譬如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理 市场经理，这样他就拥有这两个角色的所有权限。三、角色分层模型RBAC1解析：RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念。简单理解就是，给角色可以分成几个等级，每个等级权限不同，从而实现更细粒度的权限管理。举例：基于之前RBAC0的例子，我们又发现一个公司的销售经理可能是分几个等级的，譬如除了销售经理，还有销售副经理，而销售副经理只有销售经理的部分权限。这时候，我们就可以采用RBAC1的分级模型，把销售经理这个角色分成多个等级，给销售副经理赋予较低的等级即可。四、角色限制模型RBAC2解析：RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图：举例：还是基于之前RBAC0的例子，我们又发现有些角色之间是需要互斥的，譬如给一个用户分配了销售经理的角色，就不能给他再赋予财务经理的角色了，否则他即可以录入合同又能自己审核合同；再譬如，有些公司对角色的升级十分看重，一个销售员要想升级到销售经理，必须先升级到销售主管，这时候就要采用先决条件限制了。五、统一模型RBAC3解析：RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。举例：这个就不举例了，统一模型RBAC3可以解决上面三个例子的所有问题。当然，只有在系统对权限要求非常复杂时，才考虑使用此权限模型。六、基于RBAC的延展&&用户组解析：基于RBAC模型，还可以适当延展，使其更适合我们的产品。譬如增加用户组概念，直接给用户组分配角色，再把用户加入用户组。这样用户除了拥有自身的权限外，还拥有了所属用户组的所有权限。举例：譬如，我们可以把一个部门看成一个用户组，如销售部，财务部，再给这个部门直接赋予角色，使部门拥有部门权限，这样这个部门的所有用户都有了部门权限。用户组概念可以更方便的给群体用户授权，且不影响用户本来就拥有的角色权限。七、最后的话无论是本次的权限模型，还是其他产品相关实现方案，很多都已经被前人所总结提炼，我们应深度掌握这些成熟的知识和经验，而不是绞尽脑汁自我推理。还是文章开头那句话，站在巨人的肩膀上我们可以看得更远，而不是再造一个轮子。热门文章 -->关于我们产品介绍深入了解联系销售人员全国服务热线400-周一到周五 9:00-19:00周&&&&&&&&&&&六 9:00-17:30关注小满科技}