用户管理系统 - 用户权限设计(RBAC模型）
权限管控可以通俗的理解为权力限制，即不同的人由于拥有不同权力，他所看到的、能使用的可能不一样。对应到一个应用系统，其实就是一个用户可能拥有不同的数据权限（看到的）和操作权限（使用的）。
Access Control List，ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。
原理：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。
例如：当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。
缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。
Discretionary Access Control，DAC是ACL的一种拓展。
原理：在ACL模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。
例如：常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。
缺点：对权限控制比较分散，例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大，无意间就可能泄露信息。
Mandatory Access Control，MAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件。
原理：主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。
例如：将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。
缺点：控制太严格，实现工作量大，缺乏灵活性。
(Attribute-Based Access Control)，能很好地解决RBAC的缺点，在新增资源时容易维护。
原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。
属性通常有四类：
例如：早上9:00 11:00期间A、B两个部门一起以考生的身份考试，下午14:00 17:00期间A、B两个部门相互阅卷。
缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。
RBAC的核心在于用户只和角色关联，而角色代表对了权限，是一系列权限的集合。
RBAC三要素：
在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。
RBAC模型可以分为：RBAC 0、RBAC 1、RBAC 2、RBAC 3 四个阶段，一般公司使用RBAC0的模型就可以。另外，RBAC 0相当于底层逻辑，后三者都是在RBAC 0模型上的拔高。
我先简单介绍下这四个RBAC模型：
RBAC 0模型： 用户和角色、角色和权限多对多关系。
简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。
RBAC 0模型如下图：没有画太多线，但是已经能够看出多对多关系。
RBAC 1模型： 相对于RBAC 0模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如role1根节点下有role1.1和role1.2两个子节点。
角色分级的逻辑可以有效的规范角色创建（主要得益于权限继承逻辑），我之前做过BD工具（类CRM），BD之间就有分级（经理、主管、专员），如果采用RBAC 0模型做权限系统，我可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有权限。
而RBAC 1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。
RBAC 1模型如下图：多对多关系仍旧没有改变，只增加角色分级逻辑。
[图片上传中...(-95cc0-1640060170347-0)]
RBAC 2模型： 基于RBAC 0模型，对角色增加了更多约束条件。
如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。
如角色数量限制，例如：一个角色专门为公司CEO创建的，最后发现公司有10个人拥有CEO角色，一个公司有10个CEO？
这就是对角色数量的限制，它指的是有多少用户能拥有这个角色。
RBAC 2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。
RBAC 3模型： 同样是基于RBAC0模型，但是综合了RBAC 1和RBAC 2的所有特点。这里就不在多描述，读者返回去看RBAC 1和RBAC 2模型的描述即可。
RBAC 权限模型由三大部分构成，即用户管理、角色管理、权限管理。用户管理按照企业架构或业务线架构来划分，这些结构本身比较清晰，扩展性和可读性都非常好。角色管理一定要在深入理解业务逻辑后再来设计，一般使用各部门真实的角色作为基础，再根据业务逻辑进行扩展。权限管理是前两种管理的再加固，做太细容易太碎片，做太粗又不够安全，这里我们需要根据经验和实际情况来设计。
用户管理中的用户，是企业里每一位员工，他们本身就有自己的组织架构，我们可以直接使用企业部门架构或者业务线架构来作为线索，构建用户管理系统。
需要特殊注意：
实际业务中的组织架构可能与企业部门架构、业务线架构不同，需要考虑数据共享机制，一般的做法为授权某个人、某个角色组共享某个组织层级的某个对象组数据。
在设计系统角色时，我们应该深入理解公司架构、业务架构后，再根据需求设计角色及角色内的等级。一般角色相对于用户来说是固定不变的，每个角色都有自己明确的权限和限制，这些权限在系统设计之处就确定了，之后也轻易不会再变动。
（1）自动获得基础角色
当员工入职到某部门时，该名员工的账号应该自动被加入该部门对应的基础角色中，并拥有对应的基础权限。这种操作是为了保证系统安全的前提下，减少了管理员大量手动操作。使新入职员工能快速使用系统，提高工作效率。
（2）临时角色与失效时间
公司业务有时需要外援来支持，他们并不属于公司员工，也只是在某个时段在公司做支持。此时我们需要设置临时角色，来应对这种可能跨多部门协作的临时员工。
如果公司安全级别较高，此类账号默认有固定失效时间，到达失效时间需再次审核才能重新开启。避免临时账号因为流程不完善，遗忘在系统中，引起安全隐患。
（3）虚拟角色
部门角色中的等级，可以授权同等级的员工拥有相同的权限，但某些员工因工作原因，需要调用角色等级之外的权限，相同等级不同员工需要使用的权限还不相同。这种超出角色等级又合理的权限授予，我们可以设置虚拟角色。这一虚拟角色可集成这一工作所需的所有权限，然后将它赋予具体的员工即可。这样即不用调整组织架构和对应的角色，也可以满足工作中特殊情况的权限需求。
（4）黑白名单
白名单：某些用户自身不拥有某部门的顶级角色，但处于业务需求，需要给他角色外的高级权限，那么我们可以设计限制范围的白名单，将需要的用户添加进去即可。在安全流程中，我们仅需要对白名单设计安全流程，即可审核在白名单中的特殊用户，做到监控拥有特殊权限的用户，减少安全隐患。
黑名单：比较常见的黑名单场景是某些犯了错误的员工，虽然在职，但已经不能给他们任何公司权限了。这种既不能取消角色关联，也不能完全停用账号的情况，可以设置黑名单，让此类用户可以登录账号，查看基本信息，但大多数关键权限已经被黑名单限制。
权限管理一般从三个方面来做限制。页面/菜单权限，操作权限，数据权限。
（1）页面/菜单权限
对于没有权限操作的用户，直接隐藏对应的页面入口或菜单选项。这种方法简单快捷直接，对于一些安全不太敏感的权限，使用这种方式非常高效。
（2）操作权限
操作权限通常是指对同一组数据，不同的用户是否可以增删改查。对某些用户来说是只读浏览数据，对某些用户来说是可编辑的数据。
（3）数据权限
对于安全需求高的权限管理，仅从前端限制隐藏菜单，隐藏编辑按钮是不够的，还需要在数接口上做限制。如果用户试图通过非法手段编辑不属于自己权限下的数据，服务器端会识别、记录并限制访问。
数据权限如何管控
数据权限可以分为行权限和列权限。行权限控制：看多少条数据。列权限控制：看一条数据的多少个字段
简单系统中可以通过组织架构来管控行权限，按照角色来配置列权限，但是遇到复杂情况，组织架构是承载不了复杂行权限管控，角色也更不能承载列的特殊化展示。
目前行业的做法是提供行列级数据权规则配置，把规则当成类似权限点配置赋予某个角色或者某个用户。
网易有数做法：
https://youdata.163.com/index/manual/o/6System_management/data_role.html
1.超级管理员
超级管理员是用来启动系统，配置系统的账号。这个账号应该在配置好系统，创建管理员之后被隐藏起来。超级管理员账号拥有系统中全部权限，可穿梭查看各部门数据，如果使用不恰当，是系统管理的安全隐患。
2.互斥角色如何处理
当用户已经有用的角色和即将添加的角色互相互斥时，应该在添加新角色时，提示管理员因角色互斥的原因，无法进行新角色添加。如需添加，要先撤销掉前一个角色，再添加新角色。
3.用户管理权限系统设计一定要简单清晰
在设计权限系统之处，一定要理清思路，一切从简，能不增加的多余角色和权限逻辑，就一定不要增加。因为随着公司业务的扩大，权限和角色也会随之增多，如果初期设计思路不严谨，那么权限系统会随着业务的扩大而无限混乱下去，此时再来整理权限，已经太晚了。所以初期设计就一定要条理清晰，简单明了，能避免后续非常多不必要的麻烦。
4.无权提示页
有时员工 A 会直接给员工 B 分享他当下正在操作的页面，但有可能员工 B 无权查看。此时我们应该在这里考虑添加「无权提示页」，避免粗暴的 404 页面让员工 B 以为是系统出错了。
用ASP的确可以实现，但是要实现你的那些功能可能在时间上比较久一些，如果你用asp.net的话久可以很容易的搞定了，里面直接调用控件再编辑角色就可以实现你所说的高权限的用户可以管理低权限的用户
确定增进客户关系目标，系统评价客户对公司的价值和贡献，评价客户关系人对公司的价值。
选择增进客户的关系的工作任务
根据增进客户关系的工作目标，透过系列客户关怀行动和其他针对客户的个性化服务措施，让客户充分了解公司对客户的价值和贡献。
制定客户关怀计划
通过制定客户关怀计划与客户深入沟通，倾听客户的意见，随关注客户的新需求，解决客户的难题，关注企业客户资源的动态变化，挖掘客户更多更深层次的应用，为客户提供更多更新的应用，保持长久关系，争取实现经营客户的持续销售的目的。
对客户关怀进行评估
在客户关怀及管理工作中的总体战略以及文化、架构、渠道、方法等方面的综合能力；在于客户建立双向互动关怀体系时，在客户关怀策略的执行方面以及针对客户关怀策略的指引所采取的有效方法等方面的综合能力指标；客户认知度、客户满意度及客户忠诚度综合评价指标；
在信息时代，计算机、手机等通信工具和网络技术改变了电子商务市场的传统交易模式和流通模式，直接通过第三方平台完成交易，减少了中间程序。在不断创新的过程中，它改变了消费者对购物的认知和购物方式。
为了保障系统操作使用的信息安全，系统登录认证体系由三个要素组成:用户、角色、权限，三者相辅相成，共同组成系统的安全运行屏障。
(1)用户:凡是纳入到专业业务处理和日常办公系统中的工作人员，都需要在系统中定义一个身份，这个身份称为用户。
(2)角色:每个人在工作流或栏目专题中都有自己的岗位和相应处理要求，在工作中按照岗位分工处理不同的事务，称之为角色。
(3)权限:每个用户只能在自己的职责范围内进行处理，每项业务对不同用户需要分配不同的权利和限制条件，称为权限。
业务处理与信息服务子系统是一个多用户的办公系统，每个用户所处的工作流及所要处理的事件是不一样的，所以拥有的角色是不一样的，如何管理用户和给用户分配适当的角色是系统设计面临的主要问题。需要在开发设计前考虑，制定角色分配方案。管理员针对不同用户可以建立一个或多个角色，并给这些新添加的角色分配权限，之后根据用户要求给用户分配角色。一个用户在被分配角色后，即拥有了该角色所带的所有权限。被分配角色的用户即可操作相应的功能，一个用户可以拥有多个角色。具体流程如图7－23所示。
针对用户权限分配，还需要注意到:每个用户必须属于至少一个角色，每个角色具备页面的控制权限，页面权限通过角色传递给用户，从而实现用户对页面的查看管理权限。
在数据库中为页面建立权限管理表，业务处理子系统的每个页面在页面权限管理表均有记录，有页面名称和页面代码，同时记录页面的可分配权限，权限分为查看和管理。
建立权限角色间关系的是页面角色表，页面角色表记录的信息包括角色名称、页面编码、页面权限。
角色和用户的对应关系则依靠角色表，角色表记录有角色名称和用户编码。
用户表记录用户的基本信息，包括用户名、用户类型、口令、用户编码等信息，以及在其他子系统的权限编码。
通过这四个表将用户、角色与权限组合起来，可以形成无穷多的用户权限组合，直接控制用户权限到页面。
图7－23 权限管理图
在此建立用户—角色—权限的关系链，如何在页面执行过程体现查看与管理权限的区别，这就需要在页面中加入权限控制代码。在页面中管理权限用户可以操作的功能主要包括编辑输入、输出，查看权限只能浏览选择查询，无权用户不能查看。在页面初始化代码中加入控制代码，查看用户进入时隐藏编辑输入、输出等功能按钮，无权用户进入时直接返回，而管理权限用户进入时，开放所有功能按钮和区域。
页面权限表仅在部署角色权限时使用，标示页面具备的可部署权限，有些页面是纯查询的，不必要设置管理权限。
在角色中必须保证有一个管理角色拥有用户管理页面的管理权限，防止不能分配角色与权限，同样在用户中必须保证至少有一个用户是管理角色。
在此种管理模式中，允许每用户属于多个角色，每角色可对自由组合的多个页面拥有不同权限角色权限采用最大优先制，用户对同一页面的多个角色权限只以最大权限为准。
1.登录
业务处理与信息综合服务子系统的用户登录充分考虑用户使用的便捷性，采用的是一体化登陆模式，在办公系统登陆后，不但可运行办公系统功能，同时可运行业务处理系统功能和直接进入邮件系统。
在系统登录后将用户名和口令加密后作为参数启动相应的业务处理功能和邮件系统。
2.管理
基于塔里木河流域生态环境动态监测及决策系统集成的考虑，所有子系统的用户统一管理在业务处理子系统的用户表中，因此本系统的用户表设计中增加了对其他子系统用户权限的权限级别字段。
用户管理模块包括三个功能:
用户添加:添加一个新的用户，包括用户的姓名、缺省口令、登录名、类型等基本信息，以及在其他子系统的使用权限，为便于其他子系统控制使用人员，虽然每个用户均有其他子系统权限属性，但是提供无权用户选项。
用户编辑:修改用户的信息，包括基本信息和角色信息，用户角色的分配在当前角色表中多选组合。
角色分配:包括创建角色、角色权限分配。角色的创建是任意的不同名称，创建完成后需要进行角色权限的分配，角色权限的分配依据页面可分配权限进行，必须为每个页面制订角色权限。
用户管理模块不仅为业务处理与信息服务子系统服务，也为其他专业应用子系统服务，所有系统的用户全部统一在一个用户表中，该用户表存储在综合数据库中，各专业应用子系统在登录时，将访问综合数据库以确定用户的使用权限专业子系统用户权限的更改也必须通过业务处理与信息服务子系统的用户管理模块进行。
权限管理，最细致的权限管理有 用户，用户组，角色，权限，功能。根据不同的需求适当选择，如 用户量过大，每个人都授权和麻烦，就引入用户组，对用户组赋予权限。功能上也根据业务不同做适当的扩展。由于如用户权限之前存在多对多关系，需要引入中间表。
本系统设计如下：
数据量很小，功能也不复杂，所以只有用户，角色，权限（功能）及产生的中间表。
表中的数据都是提前填的，用户登陆，查ermroleuser表，获取角色，查ermrolefunction表，获取功能，再查ermfunction表，返回该用户的功能的中文，在页面上展示。
功能权限详细设计请参考，本项目也是受此启发：
http://blog.csdn.net/painsonline/article/details/7183613/
需求：给一个原来没有权限的数据配置系统加上登录，权限功能，不同角色查同一张表返回结果不同。
思路：所谓数据权限，关注点在于实体属性值、条件、允许值，用户登录后，查询该用户的查询条件，根据条件获取数据即可。详细表结构设计可以参考： https://zhuanlan.zhihu.com/p/31339794
具体介绍一下每个字段含义：
（1）主键 id；
（2）acl_id 映射权限点表主键，代表每行记录是针对哪个权限点的；
（3）status 代表当前这条配置是否有效，方便临时激活与禁用；
（4）param 代表需要校验的参数名，允许一个请求有多个参数参与数据校验；如果参数复杂，比如包含对象，定义的参数可能为a.b.c 这种多级的形式，建议不要太复杂
（5）operation 代表数据拦截的规则，使用数字代表是等于、大于、小于、大于等于、小于等于、包含、介于之间等，可以根据自己需要增加或减少支持的拦截规则
（6）value1 和 value2 用来和param、operation组成一个关系表达式，比如：1<=a<2
next_param_op 字段根据需要使用，如果一个权限点支持多条数据规则时，连接两个规则之间的操作，|| 还是 &&
（7）seq 字段用于某个权限点包含多条数据权限规则时的顺序
假设有这么一条数据，那么他的含义是：id为1（acl_id）的权限点，配置了一条有效（status=1）的数据规则，规则是：传入参数id（param）的值要大于（operation）10（value1）
这种设计很细致了，当然我的项目没有那么复杂，所以最终没有采用这个。
http://www.cnblogs.com/jeffwoot/archive/2008/12/23/1359591.html 讲述了数据权限设计的演化过程。
本系统跟权限相关的表结构如下：
