RBAC权限模型相关概念介绍
第一章 RBAC权限模型
1.1 基础表模型
1.概念
权限管理，这是每个软件系统都会涉及到的，而且权限管理的需求本质往往都是一样，不同的角色拥有不同的权限，只要你充当了某个角色，你就拥有了相对应的功能。
RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。
简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。
这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般都是多对多的关系
1.2 完整扩展模型
1.3 RBAC级别
1.3.1 级别0
RBAC级别 - RABC0
RBAC0的模型中包括用户（U）、角色（R）和许可权（P）等3类实体集合。
RABC0权限管理的核心部分，其他的版本都是建立在0的基础上的，看一下类图：
1.3.2 级别1
RBAC1，基于RBAC0模型，引入角色间的继承关系，即角色上有了上下级的区别，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。
这种模型合适于角色之间的层次明确，包含明确。
1.3.3 级别2
RBAC级别 - RABC2
RBAC2，基于RBAC0模型的基础上，进行了角色的访问控制。
RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻**一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可，此约束有多种。
互斥角色 ：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。
基数约束 ：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的*有限的；
先决条件角色 ：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。
运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时**这两个角色。
1.3.4 级别3
RBAC级别 - RABC3
RBAC3，也就是最全面级的权限管理，它是基于RBAC2的基础上，将RBAC1和RBAC2进行整合了，最全面，也最复杂的
总结
任何系统中都会涉及到权限管理的模块，无论复杂简单，我们都可以通过以RBAC模型为基础，进行相关灵活运用来解决我们的问题
基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。
RBAC1和RBAC2两者都包含RBAC0，但各自都增加了独立的特点，它们被称为高级模型。
RBAC1中增加了角色分级的概念，一个角色可以从另一个角色继承许可权。
RBAC2中增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。
RBAC3称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。这些模型构成了RBAC96模型族。
1.4 ACL模型
ACL(Access Controller List)模型
访问控制列表，是前几年盛行的一种权限设计，它的核心在于用户直接和权限挂钩。
RBAC的核心是用户和角色关联，而角色代表了权限，这样设计的优势在于使得对用户而言，只需角色即可以，而某角色可以拥有各种各样的权限并可继承。
ACL和RBAC相比缺点在于由于用户和权限直接挂钩，导致在授予时的复杂性，虽然可以利用组来简化这个复杂性，但仍然会导致系统不好理解，而且在取出判断用户是否有该权限时比较的困难，一定程度上影响了效率。
1.5 基于RBAC模型的权限框架
- Apache Shiro
参考官网视频： http://www.gulixueyuan.com/course/45
- Spring Security
可以与Spring框架无缝集成
- SELinux