RBAC_节点动态java精修学校
什么是权力管理该系统主要涉及用户参与权限管理，权限管理系统属于安全类，访问权限管理系统控制用户，根据安全或安全规则的政策控制用户可以访问，只能授权访问他们的资源。
权限管理包括用户身份认证和授权两部分，称为认证授权，首先需要认证访问权限的资源用户，用户可以访问资源，用户可以访问认证。
用户身份认证
身份认证是判断用户是否是一个合法的用户或没有的过程。简单的认证最常用的方法是检查用户名和密码是否一致的用户名和密码存储在系统来确定用户的身份是正确的，指纹和其他系统使用，显示指纹；硬件密钥和其他卡系统，你需要刷卡。
用户名密码身份认证过程
关键对象
下面的流程图需要理解以下关键对象：
主体：主体
访问系统的用户可以是用户、程序等，这些都称为主体。
n主体：身份信息
它是对主体（主体）身份的确认。标识符必须是唯一的，如用户名、手机号码、电子邮件地址等。一个主体可以有多个身份，但是必须有一个主体身份（主要的主体）。
证书：凭证信息
只有主体知道的安全信息，如口令、证书等。
授权
授权、访问控制、哪些资源可以访问。在实体被认证后，它需要分配权限访问系统的资源，而这些资源在未经许可的情况下不能访问某些资源。
授权过程
橙色是以下图表中的授权过程。
关键对象
授权可以简单地理解为谁操作什么（哪种）：
人，即身体（主体），身体需要访问系统中的资源。
n，即资源（资源），如系统菜单、页面、按钮、类方法、系统商品信息等。资源包括资源类型和资源实例。例如，商品信息资源类型、T01型商品资源的实例，和商品信息编号001也是资源实例。
n如何（权限）、权限/许可指定资源的操作许可的主题，无需资源的访问没有意义，如用户权限、用户权限、添加类方法调用权限、编号为001的用户权限、通过具有操作许可证的资源的主体权限。
权限分为粗粒度和细粒度，粗粒度权限指资源类型的权限，细粒度权限是资源实例的权限。
主体、资源和权力的关系如下：
权限模型
上一节中的主体、资源和权限由数据模型表示。
科目（帐号，密码）
资源（资源名称、访问地址）
权限（权限名称、资源ID）
角色（角色名称）
角色和权限关系（角色ID、权限ID）
身体和角色之间的关系（身体ID，角色ID）
如下：
一般情况下，资源和权限表被合并到企业开发的权限表中，如下所示：
资源（资源名称、访问地址）
权限（权限名称、资源ID）
合并成：
权限（权限的名称、资源的名称、资源访问地址）
map通常被称为权限管理的一般模型。然而，在开发过程中，企业会根据系统的特点对上层进行修改，但需要理解用户、角色、权限、用户角色和角色权限关系。
权限分配
分配权的主体，主体只允许经营资源许可的范围内，如分配商品修改U01用户的权利，用户只能修改产品和债券。
权限的数据通常需要持久化，基于上面的数据模型创建一个表，并将用户的权限信息存储在数据库中。
权限控制
用户有权在权限范围内操作资源，系统不知道主体是否具有访问权限，需要控制用户的访问权限。
基于角色的访问控制
基于角色的访问控制（基于角色的访问控制）是以角色为中心的访问控制，例如：角色的主体是总经理，可以查询业务运行报告，查询员工工资信息，访问控制流程如下：
上图中的逻辑代码可以理解为：
如果（这principal.hasrole（的作用，总经理ID））{
查询工资
}
缺点：基于角色的访问控制粒度较粗。如果将查询工资所需的角色改为总经理和部门经理，则需要修改判断逻辑来决定主体的角色是否是总经理或部门经理，因此系统的可伸缩性差。
修订后的代码如下所示：
如果（这main.hasrole（总经理角色ID（。hasrole）| |学科部门经理的角色ID））{
查询工资
}
基于资源的访问控制
基于RBAC资源访问控制（基于资源的访问控制）是以资源为中心的访问控制。例如，主体必须具有查询雇员工资信息的查询工资权限。
上图中的逻辑代码可以理解为：
如果（主。有权限））{
查询工资
}
优点：系统设计定义了工资支票权限标识，即使查询工资需要变动，总经理和部门经理也只需要查询工资信息权限，将权限添加到权限管理器的角色列表中，逻辑上无需修改系统的可伸缩性。
权限管理方案
粗粒度和细粒度
什么是粗粒度和细粒度
The management of resource types is called coarse granularity permission management, that is, only control to menus, buttons, methods, coarse grained examples, such as: users have the right of user management, and have the right to export order details.The control of resource instances is called fine granularity permission management, that is, control to data level permissions, such as: users can only modify employees' information in the Department, and users can only export the order details that they create.
如何实现粗粒度和细粒度
粗粒度的权限管理可以很容易地完成系统体系结构级的功能，即系统功能操作采用统一的粗粒度权限管理。
对于细粒度的权限管理系统的架构不推荐了级别的功能，因为数据水平的控制是系统的业务需求，以改变在个性发展，业务层对数据级的访问控制的很好的建议的操作等需求的可能性：只允许用户修改自己创造的商品信息可以被添加到查询的服务界面，输入电流操作识别服务接口的需要，创建商品信息相比，个人识别，或不允许修改商品信息。