现在比较普遍的权限管理模型就是RBAC(Role-Based Access Control)。

　　1. 权限控制分类

　　菜单功能

　　url控制(控制访问不同的控制器)

　　2. RBAC的优缺点

　　2.1 优点

　　简化了用户和权限的关系

　　易扩展、易维护

　　2.2 缺点

　　RBAC模型没有提供操作顺序的控制机制，这一缺陷使得RBAC模型很难适应哪些对操作次序有严格要求的系统。

　　3. RBAC支持的安全原则

　　3.1 最小权限原则

　　RBAC可以将角色配置成其完成任务所需的最小权限集合。

　　3.2 责任分离原则

　　可以通过调用相互独立互斥的角色来共同完成敏感的任务，例如要求一个记账员和财务管理员共同参与统一过账操作。

　　3.3 数据抽象原则

　　可以通过权限的抽象来体现，例如财务操作用借款、存款等抽象权限，而不是使用典型的读写权限。

　　4. 远古时代的权限控制模型

　　当时还没有RBAC，也没有这个概念，就是一堆程序员在那鼓捣，觉得登录这块该做点什么，基本逻辑如下：

　　新建一个用户，对这个用户进行赋予权限。

　　但是一旦用户多了，权限复杂了，这工作量也是蛮大的。

　　5. RBAC模型

　　5.1 RBAC 1.0

　　直接上图，一目了然，当程序不是很复杂的时候，RBAC就是这样设计的，我们公司的权限验证模块就是这样设计的。简简单单，五张表，解决。

　　5.2 RBAC 2.0

　　基于RBAC 1.0模型的基础上，进行了角色的访问控制。

　　RBAC2中的一个基本限制是互斥角色的限制，互斥角色是指各自权限可以互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。

　　该模型有以下几种约束：

　　互斥角色 ：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。

　　基数约束 ：一个角色被分配的用户数量受限;一个用户可拥有的角色数目受限;同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人有限的;

　　先决条件角色 ：可以分配角色给用户仅当该用户已经是另一角色的成员;对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。

　　运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。

　　6. rbac的实现理论分析步骤

　　进入登录页面;

　　拿到通过post传过来的用户名和密码;

　　使用orm进行过滤查找;

　　如果能找到值，则说明登录成功：登录成功后调用rbac初始化函数，初始化函数的主要功能是获取用户的权限和菜单保存到session中，并跳转客户列表页面;如果失败，页面进行友好提示;

声明：本站稿件版权均属千锋教育所有，未经许可不得擅自转载。