粤嵌星计划打卡第三十二天（对象的销毁和垃圾收集机制）（java实现一个权限管理系统）

#粤嵌我来了##粤嵌星计划#
粤嵌星计划挑战
今天打卡第三十二天
今天学习内容
知识清单
1.了解基于资源的权限管理方式
2. 掌握权限数据模型
3. 掌握基于url的权限管理(不使用Shiro权限框架的情况下实现权限管理)
4. shiro实现用户认证
5. shiro实现用户授权
6. shiro与企业web项目整合开发的方法
权限管理原理知识
什么是权限管理
只要有用户参与的系统一般都要有权限管理，权限管理实现对用户访问系统的控制。按照安全规则或安全策略控制用户可以访问而且只能访问自己被授权的资源。
权限管理包括用户认证和用户授权两部分。
用户认证
用户认证概念
用户认证—— 用户去访问系统，系统需要验证用户身份的合法性。最常用的用户身份认证方法：1.用户密码方式、2.指纹打卡机、3.基于证书的验证方法。系统验证用户身份合法，用户方可访问系统的资源。
用户认证流程

关键对象
subject：主体，理解为用户，可能是程序，都要去访问系统的资源，系统需要对subject进行身份认证。
principal：身份信息，通常是唯一的，一个主体可以有多个身份信息，但是只能有一个主身份信息(primary principal)。
credential：凭证信息，可以是密码、证书、指纹等。
总结：主体在进行身份认证时需要提供身份信息和凭证信息。
用户授权
用户授权概念
用户授权，简单理解为访问控制，在用户认证通过后，系统对用户访问资源进行控制，当用户具有资源的访问权限方可访问。
授权流程

其中橙色为授权流程
关键对象
授权的过程可以理解为 who 对 what(which) 进行how操作
who：主体，即subject，subject在认证通过后，系统进行访问控制。
what(which)：资源(Resource) ，subject必须具备资源访问权限才可以访问该资源。资源包括很多方面比如：用户列表页面、商品修改菜单、商品id为001的商品信息。
资源分为资源类型和资源实例：
例如系统的用户信息就是资源类型，相当于Java类。
系统中id为001的用户就是资源实例，相当于new的Java对象。
how：权限/许可(permission)，针对资源的权限或许可，subject必须具有permission方可访问资源，如何访问/操作需要定义permission，权限比如：用户添加、用户添加、商品删除。
权限模型
主体（账号、密码）
资源（资源名称，访问地址）
权限（权限名称、资源id）
角色（角色名称）
角色和权限关系（角色id、权限id）
如下图：

通常企业开发中将资源和权限合并为一张权限表，如下：
资源（资源名称、访问地址）
权限（权限名称、资源id）
合并为：
权限（权限名称、资源名称、资源访问地址）

上图被称为权限管理的通用模型，不过在企业开发中根据系统自身特点还会对上图进行修改，但是用户、角色、权限、用户角色关系、角色权限关系是必不可少的。
分配权限
用户需要分配相应的权限才可以访问相应的资源。权限是对资源的操作许可。
通常给用户分配资源权限需要将权限信息持久化，比如存储在关系数据库中。
把用户信息、权限管理、用户分配的权限信息写入到数据库（权限数据模型）。
权限控制(授权核心)
基于角色的访问控制
RBAC (Role based access control) 基于角色的访问控制
比如：
系统角色包括：部门经理、总经理…（角色针对用户进行划分）
系统中代码实现：
//如果该user是部门经理则可以访问if中的代码
if(user.getRole(“部门经理”)){
// 系统资源内容
// 用户报表查看
}
问题：
角色是针对人进行划分的，人作为用户在系统中属于活动内容，如果该角色可以访问的资源出现变更，则需要修改代码，比如：需要变更为部门经理和总经理都可以进行用户报表查看，代码改为：
if(user.getRole(“部门经理”) || user.getRole(“总经理”)){
// 系统资源内容
// 用户报表查看
}
由此可以发现基于角色的访问控制是不利于系统维护的(可扩展性不强)
基于资源的访问控制
RBAC (Resource based access control) 基于资源的访问控制
资源在系统中是不变的，比如资源有：类中的方法，页面中的按钮
对资源的访问需要具有permission权限，代码可以写为：
if(user.hasPermission(“用户报表查看(权限标识符)”)){
// 系统资源内容
// 用户报表查看
}
上面的方法就可以解决用户角色变更而不用修改上边权限控制的代码。
如果需要变更权限只需要在分配权限模块去操作，给部门经理或总经理增加或解除权限
建议使用基于资源的访问控制实现权限管理。
权限管理解决方案
什么是粗粒度权限和细粒度权限？
粗粒度权限管理，是对资源类型的管理，资源类型比如：菜单、url连接、用户添加页面、用户信息、类方法、页面中按钮。
粗粒度权限管理比如：超级管理员可以访问用户添加页面、用户信息等全部页面。
部门管理员可以访问用户信息页面，包括页面中所有按钮。

细粒度的权限管理，对资源实例的权限管理。资源实例就是资源类型的具体化，比如：用户id为001的修改连接，1110班的用户信息、行政部的员工。
细粒度的权限管理就是数据级别的权限管理。
细粒度权限管理比如：部门经理只可以访问本部门的员工信息，用户只可以看到自己的菜单，大区经理只能查看本辖区的销售订单…

粗粒度和细粒度例子：
系统中有一个用户查询页面，对用户列表查询分权限，如粗粒度管理，张三和李四都有用户列表查询的权限，张三和李四都可以访问用户列表查询。
进一步进行细粒度的管理，张三(行政部)和李四(开发部)只可以查询自己本部门的用户信息，张三只能查看行政部的用户信息，李四只能查询开发部门的用户信息。细粒度的权限管理就是数据级别的权限管理。
如何实现粗粒度和细粒度的权限管理
如何实现粗粒度的权限管理？
粗粒度权限管理比较容易将权限管理代码抽取出来在系统架构级别统一管理。比如：通过SpringMVC的拦截器实现授权。
如何实现细粒度的权限管理？
对细粒度的权限管理在数据级别是没有共性可言的，针对细粒度的权限管理就是系统业务逻辑的一部分，如果在业务层去处理相对简单，如果将细粒度的权限管理统一在系统架构级别去抽取，比较困难，即使进行了抽取，功能也可能存在扩展性不全的弊端。建议细粒度权限管理放在业务层去控制。比如：部门经理只查询本部门员工信息，在Service接口提供一个部门id的参数，controller中根据当前用户信息得到该用户属于哪个部门，调用service时将部门id传入service，实现该用户只查询本部门的员工。
基于url拦截的方式实现
基于url拦截的方式实现在实际开发中是比较常用的一种方式。
对于web系统，通过filter过滤器实现url拦截，也可以通过SpringMVC的拦截器实现基于URL的拦截。
使用权限管理框架来实现
对于粗粒度的权限管理，建议使用优秀的权限管理框架进行实现，节省开发成本，提高开发效率。
Shiro就是一个优秀的权限管理框架。
基于URL的权限管理
基于url的权限管理流程