基本常见的就是 基于RBAC
Role-based Access Control，基于角色的权限控制模型。
顾名思义，给用户定义角色，通过角色来控制权限。目前来说基于角色权限控制模型是应用较广的一个。特别是2B方向SAAS领域，应用尤其常见。
如上图示，用户拥有角色，且可拥有多个角色，而每个角色对应不同权限。
这样的好处是：不必为每一个用户去配置权限，拥有极大的灵活性和便利性。
1. 概念
访问控制技术是由美国国防部（Department of Defense, DoD）资助的研究和开发成果演变而来的。这一研究导致两种基本类型访问控制的产生：自主访问控制（Discretionary Access Control, DAC）和强制访问控制（Mandatory Access Control, MAC）。最初的研究和应用主要是为了防止机密信息被未经授权者访问，近期的应用主要是把这些策略应用到为商业领域。
自主访问控制，允许把访问控制权的授予和取消留给个体用户来判断。为没有访问控制权的个体用户授予和废除许可。自主访问控制机制允许用户被授权和取消访问其控制之下的任何客体（object），换句话说，用户就是他们控制下的客体的拥有者。对于这些组织，公司或代理机构是事实上的系统客体和处理他们的程序的拥有者。访问优先权受组织控制，而且也常常基于雇员功能而不是数据所有权。
强制访问控制，在美国国防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定义如下：“一种限制访问客体的手段，它以包含在这些客体中的信息敏感性和访问这些敏感性信息的主体的正式授权信息（如清除）为基础”。
什么是基于角色访问控制（Role-Based Access Control, RBAC）？NIST 有如下定义。
访问是一种利用计算机资源去做某件事情的的能力，访问控制是一种手段，通过它这种能力在某些情况下被允许或者受限制（通常是通过物理上和基于系统的控制）。基于计算机的访问控制不仅可规定是“谁”或某个操作有权使用特定系统资源，而且也能规定被允许的访问类型。这些控制方式可在计算机系统或者外部设备中实现。
就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织的一部分。用户具有指派的角色（比如医生、护士、出纳、经理）。定义角色的过程应该基于对组织运转的彻底分析，应该包括来自一个组织中更广范围用户的输入。
访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。例如，在一个医院系统中，医生角色可能包括进行诊断、开据处方、指示实验室化验等；而研究员的角色则被限制在收集用于研究的匿名临床信息工作上。
控制访问角色的运用可能是一种开发和加强企业特殊安全策略，进行安全管理过程流程化的有效手段。
2. 核心对象模型设计（RBAC0）
根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型.对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、控制对象（Resource Class）、访问模式（Access Mode）、操作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：
1. 控制对象：是系统所要保护的资源（Resource Class），可以被访问的对象。资源的定义需要注意以下两个问题：
a) 资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。
b) 这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑：
i. 一方面，资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。 例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操作，可以修改属于自己管辖的信息内容。
ii. 另一方面，资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。
2. 操作（权限）：完成资源的类别和访问策略之间的绑定。
3. 用户：权限的拥有者或主体。用户和权限实现分离，通过授权管理进行绑定。
4. 用户组：一组用户的集合。在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。
5. 角色：权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。
6. 分配角色权限PA：实现操作和角色之间的关联关系映射。
7. 分配用户角色UA：实现用户和角色之间的关联关系映射。
3. HR数据权限模型设计初稿
3.1. 访问主体
在本系统中访问主体是员工和用户组。
如图3.1.1中每个主体都有多个角色。每个角色又可能同时属于多个主体。
公司、部门、职位一定有对应的一个用户组，但用户组不一定是公司、部门、职位当中一个，也可能是虚拟出来的一个组，比如：工会组织、公司篮球队等等。
3.2. 分配用户角色（Users Assignmen）
如图3.1.1这里的Users指的是所有访问主体。用户组、员工。
用户组是可以无限制扩充的。
无论添加几个主体到最后都会映射到角色（roles）表中，成为多个角色。
然后对角色分配访问权限控制。
3.3. 操作
操作（权限）=访问模式+资源（resource class）
如图3.3.1，比如：页面A有个查询员工信息的功能，我们在这里把他看成一个“访问客体”，被权限控制的资源（resource class）。再假设访问模式中有个“运行”模式，那么两者组合起来就是有个有效的操作（权限），然后把这个权限赋予角色，就OK了。
（图3.3.1）
3.4. 分配角色权限（Permission Assignment）
3.3节中提到，根据资源和访问模式、我们这里就有了很多操作，也就是权限。
那么我们只需要把这些权限分配到角色就可以了。如图3.4.1
（图3.4.1）
3.5. 资源类别（Resources Class）
根据以上的描述可以看出来，在本模型中主体是可以无限制扩充的。那么客体呢？我们可以看到，不管你有多少客体，到最后也都是分解成了多个资源类别（和主体一样，把每个主体都分解成了多个角色），然后和访问模式组成了操作（权限），最后赋给角色。
我们再分析下资源类别模型。
我认为我们系统的资源类别可以分为2个方向，页面功能和流程。
比如：员工资料查询，这个页面上就有查询这个客体资源类别。
而员工转正流程中又有直接主管审批这个资源。
那么我们把资源类别（resources class）设计成如图3.5.1
（图3.5.1）
功能模块表中存放“流程”或“页面功能”。
“功能模块类别”用来区分，这条记录是“页面功能”还是“流程”。
一个流程有多个审批操作。我们可以放到资源类别中。
页面功能同理。
4. 小结
该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于操作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。如表4.1
|
用户 能力 |
员工1 |
员工2 |
员工3 |
员工4 |
|
查看自己部门员工通讯录 |
部门员工 |
部门员工 |
部门员工 |
部门员工 |
|
查看自己部门员工全部资料 |
部门经理 |
|
|
|
|
查看自己公司员工通讯录 |
部门员工 |
部门员工 |
部门员工 |
部门员工 |
|
查看自己公司员工全部资料 |
|
|
档案管理员 |
|
（表4.1）
图4.1为整个权限模型。
（图4.1）
5. 思考
5.1. 相对角色
在很多时候我们都会用到相对角色这个概念。比如：员工转正流程中就有个直接主管审批，那么这个直接主管这个角色就是一个相对角色。这个相对角色在数据库权限模型中其实也是一个角色，只用添加到角色表中给这个角色赋权限（操作）就可以了，但在开发过程中一定要注意相对角色的设定，特别是设定方法，公式。
5.2. 用户组的联想
用户组可以是组织架构中的实体单位。同时也可以是虚拟的，由用户自己添加、配置的一个角色的集合。角色又是权限的集合。
那么我们可以这么做，添加一个系统管理员组，然后通过角色为这个组，分配好应有的权限。以后如果有新的系统管理员，我们只需要放到这个组里面去就可以，没必要再重新配置一个用户。
这样就完全可以实现windows的权限管理了。
5.3. 角色的继承
给角色分配权限（操作）其实也是件比较复杂的工作。如果角色间存在一定的关系，可以直接把另外一个角色的权限直接复制过来，然后再添加自己需要的其他权限，这样不是会方便很多吗？
继承可分为两种方式，一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系（不能继承自己的子类），允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构（单继承）。
5.4. 资源实例（Resource Instance）
场景1：有一个功能页面，查询员工资料。可访问角色有“人事专员”和“部门经理”。“人事专员”进入可以查出全公司的所有员工资料。“部门经理”进入后，只能查出自己部门的员工资料。
场景1的解决方案：
1. 在功能模块（functionmodule）表中添加“查询员工资料”这个功能。
2. 在功能资源（functionresource）表中添加这个“查询员工资料”的两个资源，“部门经理查询”和“人事专员查询”。
3. 抽象成资源类别（resourcesclass）。
4. 资源类别（resourcesclass）和访问模式（accessmode）组合成2个操作（权限）。
5. 把这两个权限分别赋予部门经理组所拥有的角色和人事专员组所拥有的角色。
6. 在开发过程中就可以根据两个不同的资源，在这个页面做查询条件的处理。
场景2：有一个功能页面，部门花名册。可访问角色有“部门经理”和任何登录后的员工。根据员工部门自动显示所在部门的花名册。如果是“部门经理”，就显示一些“部门经理”可以看到的敏感信息。比如，工资。
场景2的解决方案：
1. 在功能模块（functionmodule）表中添加“部门花名册”这个功能。
2. 在功能资源（functionresource）表中添加这个“部门花名册”的一个资源，“部门经理花名册”。
3. 抽象成资源类别（resourcesclass）。
4. 资源类别（resourcesclass）和访问模式（accessmode）组合成1个操作（权限）。
5. 把这个权限赋予部门经理组所拥有的角色。
6. 在开发过程中进入这个功能页面，没有这个权限的显示一般花名册。有这个权限的显示部门经理花名册。
小结：
资源实例让我们在按钮级权限的基础上，加上了对记录和字段的控制。当然，你也可以把场景1和场景2结合起来。记录、字段一起控制，这个肯定是可以的。
再扩展下。场景二中，如果有一天部门经理所能看到的东西改变了，加一项或少一项，怎么办呢？难道去改代码？
其实在很多情况下，都是可以做死的。比如场景二中大家都只能看到自己部门的花名册。肯定不会有一天要看公司的花名册，如果真有这个需求，那么就应该再做个功能页面。叫做“公司花名册”。
但也有些情况，是要可以调整的。同样是场景二，部门经理能看到的东西。哪天公司想变变，这个也是有可能的。
其实这个功能实现起来也非常简单。如图5.4.1。
无论什么，到最后都会变成资源类别，我们直接给这个类别记录一些属性。到时候你只要根据这些属性显示就可以了，要变的时候把这些属性变了就行了。只要愿意，完全可以做个维护页面。
表资源设置（resourcesetting）记录一些访问条件。比如，这个资源按部门查询。如果需要你可以把他改成按公司查询。
表字段设置（fieldsetting）记录的是这个资源的字段信息。比如，部门经理可以看到“部门花名册”的字段。
（图5.4.1）
6. 总结
本模型的主要设计思想是把所有访问主体，包括部门、职位、公司、人等等。全部分解成一个或多个角色。
把所有访问控制客体全部分解成一个和多个资源类别（Resources Class）。
把资源类别加*问模式（读、写、删、运行等）成为一个操作，也就是权限。
然后把这个权限赋予到角色。
这个模型支持页面级权限、按钮级权限、记录级权限、字段级权限和这几种权限的任意组合。
在角色的分配上。他本身是支持一个客体有多个角色，一个角色属于多个客体。支持用户组角色、角色继承、相对角色等。特别是用户组这个设计。部门、职位、公司这些组织都可以抽象成一个用户组，直接给这个组分配权限就可以了。但用户组不仅仅只有抽象实体组织这功能，他还可以无限制的扩展。比如可以添加一个虚拟的系统管理员组。他本身就是一个员工的集合，你可以以任何形式去组合人员
在互联网产品中，海量用户的背后，产品所服务的用户角色往往并不是单一的。在交互设计日常的实际项目中，经常会遇到由于用户角色差异而产生的多权限模型设计。所谓多用户角色模型，是指单一的内容整体在不同场景，不同对象权限下的不同展示形式。在某些情况下，单一的内容整体会随着对象权限的差异性进行页面交互形态的再设计。
在产品应用中，模块化的页面形态和内容所要呈现的目标用户并不是单一的，而是会随着用户属性的不同发生着变化，作为交互设计师的项目日常，同一个产品中的同一个模块，为多类用户设计的需求场景不在少数。这一类的需求场景相对于单一用户角色的项目而言，需要从更多维度去了解每种用户角色的需求利益点，从而在不同的用户角色和不同的权限条件下提供差异性&协作性的产品服务。
总结一下，日常项目中经常遇到的多权限场景主要可以分为以下几种类型：
- 大量权限：“千人千面”，利用大数据进行页面的个性化设计呈现；
- 双权限（三权限）：模块平台连接两类相互作用的用户对象，常见于O2O等应用场景；
- 多权限：线性信息流，常见于To B端的业务信息流。
1. 大量用户权限：“千人千面”，利用大数据进行页面的个性化设计呈现
该种应用场景最多的是大型电商产品的首页，海量的商品SKU和用户UV，用户属性的千差万别，“千人一面”的界面已经很难满足用户的个性化需求，高效而精准地链接不同用户的需求和商品推荐成了“千人千面”地进行用户极度权限细分所扮演的重要角色。
那前期从用户自身的行为数据出发，用户侧如何获取个性化的权限，进而被系统推荐个性化的页面运营策略，设计的基本流程如下：这类用户权限的获取是基于用户多维属性标签形成的特定身份角色。
在大数据的背景下，用户权限的无限细分会对产品设计开发的工作量形成挑战。在“千人千面”用户细分的下游，衍生出了诸如“鲁班”类的个性化设计呈现工具，基于海量的数据，用户的权限可以被细分到惊人的程度，由此带来的是个性化设计工作量的井喷增长。高效的AI设计工具正是迎合了由用户权限的无限细分带来的设计工作量井喷式增长的需求。 2016 年，鲁班首次服务双 11，制作了 1.7 亿张商品banner。2017 年双 11 有 4 亿张人工智能海报由AI设计完成。如果全靠设计师人手来完成，假设每张图需要耗时 20 分钟，满打满算需要 100 个设计师连续做 300 年。如此高效率的AI设计工具为用户权限（角色）的无限细分创造了可能。
2. 双权限：模块平台连接两类相互作用的用户对象，常见于O2O等应用场景
这类用户权限是基于用户在产品服务中的角色定位，在有些产品场景中可能会有三权限的情况，但双权限仍然适用于大多数情况。
这一类型的多权限内容模块多应用于关联两种相互作用的用户对象中，用户A和用户B同为产品的服务对象，在用户角色需求上，既互相关联，又存在差异。在设计前期需要分别分析他们各自的需求利益点，相同的做合并处理，拆分具有差异性的，继而在设计上满足不同角色用户对于产品服务的差异性需求。常见的产品场景中互相关联的用户角色关系：
对于这一类的应用场景，遵循一般的设计流程：
- 明确模块的基本功能目标；
- 对于用户A和用户B的共同需求保持通用；
- 对用户A和用户B的差异性需求做出分析。
以顺风车应用场景为例，在顺风车产品中平台服务车主和乘客双方，那么在某些涉及车主和乘客相互协作的模块信息时，可以对标上述设计流程具体来看，如下：
（1）明确模块的基本功能目标
乘客和司机的角色是相互作用的，两种角色各自的任务信息流如下图所示，为了便于说明，在此取其中的 待出发信息详情（主要是指乘客在被司机接单——上车，而司机是在接到乘客需求——接到乘客这期间，姑且将其称为 待出发信息详情）信息流进行分析。
待出发详情模块主要功能是为了向应用的服务各方提供出发前状态的基本信息。
（2）对各用户角色所对应的信息流进行需求分析
在待出发信息详情模块中，乘客和司机的主要需求点。
作为乘客，主要的需求点在于：
- 事先与司机约定的上车时间、地点，提醒自己及时赴约。
- 获知司机的主要信息（电话等联系方式、IM沟通组件、当前行驶路线）以便于及时的与司机沟通上车前事宜。
- 导航、取消订单等其他操作需求
作为司机，主要的需求点在于：
- 乘客的上车时间、地点；提醒自己及时去接乘客。
- 乘客的主要信息（电话等联系方式、IM沟通组件）；以便于及时的与其沟通上车前事宜。
- 导航、取消订单等其他操作需求
- 拼其他乘客；作为顺风车司机，乘客拼车数量最大化能使车主拼车收益最大化，也符合顺风车低碳、环保、提高用户出行效率的产品定位。
- 开始行程；司机作为拼车收益获得方，应由其记录行程。
（3）对各用户角色分析得到的需求利益点进行合并和拆分处理
有效地分析了各种用户角色的需求关系，并对其中的各需求点进行有效地合并和拆分，并在此基础上确定产品的设计目标。
3. 多权限：线性信息流，常见于To B端的业务信息流
在To B在线协作流程中，用户角色所对应权限的概念被提升到更高的层面。在该场景中，用户权限既不是基于用户自身的标签属性，也不是基于用户自身的角色定位，而是基于用户在To B协作中的组织职能。且该权限关系往往对标线下组织架构的实际职能关系。对于这一类的多用户角色模型的设计流程，大致可以分成以下2个阶段：
（1）明确组织的职能架构
一个庞杂的To B 系统中，往往包含若干条多线并行的信息流。常用的如：报销、请假、权限使用、移动审批等。在设计相关需求时，需要首先明确该需求对应信息流的组织职能架构。举例说明，在同一个To B 系统中，报销流程和请假流程对应信息流所涉及的职能岗位很大程度上是不一致的。因此在设计之前首先应该梳理目标设计流程所对应的职能架构。
（2）分别对标各职能岗位节点的权限信息
以传统OA报销审批为例，在1)中首先明确了OA报销审批对应的职能信息流，接下来按照各职能岗位的节点来梳理对应的权限需求点。
4. 小结
在海量的移动应用中，同时为多类用户角色服务的产品场景非常多，以上只是基于日常工作列举的三种常见形式。在针对这些场景中的需求设计时，往往不能单一维度地去思考用户的需求点，需要将各种用户角色之间的需求点按照时间&场景的维度去连接，才能保证产品的易用性和平台协作的高效性。
原文链接：https://www.cnblogs.com/ttcre2/archive/2008/07/24/1250591.html
http://www.woshipm.com/pd/2174816.html
http://www.woshipm.com/ucd/1036860.html
https://www.cnblogs.com/skypurple/archive/2010/10/08/1845764.html
