Spring Security（二）

认证和授权

authentication：认证，认证访问者是谁。一个用户或者一个其他系统是不是当前要访问的系统中有效用户。
authorization：授权，访问者能做什么

RBAC是什么？

RBAC 是基于角色的访问控制（Role-Based Access Control ）在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。

RBAC 又分为RBAC0、RBAC1、RBAC2、RBAC3
RBAC0、RBAC1、RBAC2、RBAC3简单介绍。
RBAC0：是RBAC的核心思想。
RBAC1：是把RBAC的角色分层模型。
RBAC2：增加了RBAC的约束模型。
RBAC3：其实是RBAC2 + RBAC1。

RBAC0模型：

1.用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户担当。

2.用户和角色是多对多关系，即：一个用户可同时充当多种角色，一种角色可以有多个用户担当。（我们的系统就是使用的多对多）

那么，什么时候该使用多对一的权限体系，什么时候又该使用多对多的权限体系呢？

如果系统功能比较单一，使用人员较少，岗位权限相对清晰且确保不会出现兼岗的情况，此时可以考虑用多对一的权限体系。其余情况尽量使用多对多的权限体系，保证系统的可扩展性。如：张三既是行政，也负责财务工作，那张三就同时拥有行政和财务两个角色的权限。

RBAC1模型：
相对于RBAC0模型，增加了子角色，引入了继承概念，即子角色可以继承父角色的所有权限。

使用场景：如某个业务部门，有经理、主管、专员。主管的权限不能大于经理，专员的权限不能大于主管，如果采用RBAC0模型做权限系统，极可能出现分配权限失误，最终出现主管拥有经理都没有的权限的情况。

而RBAC1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持在经理权限上删减主管权限。

RBAC2模型：
基于RBAC0模型，增加了对角色的一些限制：角色互斥、基数约束、先决条件角色等。

• 角色互斥：同一用户不能分配到一组互斥角色集合中的多个角色，互斥角色是指权限互相制约的两个角色。案例：请款系统中一个用户不能同时被指派给申请角色和审批员角色。
• 基数约束：一个角色被分配的用户数量受限，它指的是有多少用户能拥有这个角色。案例：一个角色专门为公司CEO创建的，那这个角色的数量是有限的。
• 先决条件角色：指要想获得较高的权限，要首先拥有低一级的权限。案例：先有副总经理权限，才能有总经理权限。
• 运行时互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色，案例：同一个用户拥有多个角色，角色的权限有重叠，以较大权限为准。

RBAC3模型：
称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内，综合了RBAC0、RBAC1和RBAC2的所有特点，既有角色分层又有约束的一种模型。

产品经理说的用户组又是什么？

当平台用户基数增大，角色类型增多时，如果直接给用户配角色，管理员的工作量就会很大。这时候我们可以引入一个概念“用户组”，就是将相同属性的用户归类到一起。

例如：加入用户组的概念后，可以将部门看做一个用户组，再给这个部门直接赋予角色（1万员工部门可能就几十个），使部门拥有部门权限，这样这个部门的所有用户都有了部门权限，而不需要为每一个用户再单独指定角色，极大的减少了分配权限的工作量。

同时，也可以为特定的用户指定角色，这样用户除了拥有所属用户组的所有权限外，还拥有自身特定的权限。

用户组的优点，除了减少工作量，还有更便于理解、增加多级管理关系等。如：我们在进行组织机构配置的时候，除了加入部门，还可以加入职级、岗位等层级，来为用户组内部成员的权限进行等级上的区分。