Shiro入门2：权限管理入门，用户认证、授权

//==============================================================
//权限管理原理：【以上图为准】
//==============================================================
什么是权限管理:
|---解决的问题是：允许什么样的用户访问，允许用户访问什么样的资源
|---只要有用户参与的系统，都有权限管理
|---按照安全规则或者安全策略控制用户
|---权限管理包括用户的认证和授权

//==============================================================
用户的认证概念
|---用户去访问系统，系统要验证用户身份的合法性。
|
|---验证方式多种多样：
|	|---用户名+密码
|	|---指纹打开机：特征身份标识
|	|---基于证书验证方法
|
|---系统验证用户身份合法，用户方可访问系统资源

用户认证的流程
|---匿名访问：不用认证，即可访问
|---认证不通过：继续认证

关键对象：
|---subject:主体，可以理解为访问对象，都要去访问系统的资源，系统需要对subject进行身份认证。
|---principal:身份信息：通常是唯一的，一个主体有多个身份信息，但是都有一个主身份信息（手机号、用户名、邮箱、绑定QQ等）
|---credential:凭证：可以是密码、证书、指纹。
|---总结：主体在进行身份认证时需要提供身份信息和凭证信息。

此文老猫原创，转载请加本文连接：/article/11906596.html
更多有关老猫的文章：http://blog.csdn.net/nthack5730
//==============================================================
用户授权
|---简单理解为访问控制
|---在用户通过验证后，系统对用户访问的资源进行控制。用户具有资源的访问权限方可访问。

授权流程：
|---没有访问权限：拒绝访问

关键对象
|---授权的过程：who对what(which)进行how操作
|---who：主体即subject，subject在认证通过后系统进行访问控制
|---what(Which)：资源(resource)：subject必须具备资源的访问权限，方可访问该资源。
|	|---资源分为资源类型和资源实例
|	|
|	|---资源类型：相当于Java类
|	|	|---系统的用户信息。
|	|
|	|---资源实例：相当于new的java对象
|	|	|---商品id为001的商品信息。
|
|---how：权限或许可(permission)，针对资源的权限或许可，subject必须具有permission才可访问资源，如何操作、访问，就必须定义permission
|	|---用户添加
|	|---用户修改
|	|---商品删除

//==============================================================
分配权限
|---用户需要分配相应的权限，才可访问相应的资源，权限是对于资源的操作许可。
|---通常给用户分配资源权限，需要将全县信息持久化：存储在数据库中。
|---把用户信息、权限管理、用户分配的权限信息写到数据库中
|---分配权限模块

//==============================================================
权限模型
|---用户
|---资源
|---权限

此文老猫原创，转载请加本文连接：/article/11906596.html
更多有关老猫的文章：http://blog.csdn.net/nthack5730
//==============================================================
权限控制（授权核心）
|---基于角色的访问控制：RBAC:R(role)B(base)A(access)C(control)
|	|---如：系统的角色包括部门经理、总经理.....(角色：针对用户来划分)
|	|	|---系统代码实现：
|			//如果该用户是部门经理则可以访问if中的代码
|			if(userHasRole("部门经理")){
|				//系统资源内容
|				//用户报表查看
|			}
|
|	|---问题：角色针对人划分的，人作为用户在系统中属于活动内容。如果该角色可以访问的资源出现变化，这时候就需要修改代码。
|		|---如：需要变更为部门经理和总经理都可以查看报表，代码变更：
|			if(userHasRole("部门经理") || userHasRole("总经理")){
|				//系统资源内容
|				//用户报表查看
|			}
|
|	|---因此：基于角色的访问控制是不利于系统维护的（可扩展性不强）
|
|
|---基于资源的访问控制：RBAC(Resources Based access control)
|	|---资源在系统中是不变的，比如资源有：类中的方法、页面中的按钮
|
|	|---对资源的访问需要具有permission全新啊，代码可以写为：
|			if(userHasPermission("用户报表查看"【权限标识符】)){
|				//系统资源内容
|				//用户报表查看
|			}//这个人有资源查看的权限就可以查看报表
|		|---上面的这种方式就可以解决用户角色变更而不用改权限控制的代码
|
|	|---假设：部门经理需要查看报表，那么就给部门经理增加权限，其他人需要的话也进行同样的操作即可。代码不用改。
|	|---即：如果需要变更权限，只需要在分配权限模块操作，给部门经理或总经理增加或删除权限。
|
|---推荐使用基于资源的访问控制

此文老猫原创，转载请加本文连接：/article/11906596.html
更多有关老猫的文章：http://blog.csdn.net/nthack5730

//==============================================================
// 权限管理解决方案
//==============================================================
|---什么是粗粒度和细粒度
|	|---粗粒度：对资源类型的权限管理。
|	|---细粒度：对资源实例的权限管理。数据级别的权限管理。
|
|---资源类型和资源实例
|	|---资源类型：菜单、URL链接、用户添加页面、用户信息、类方法
|	|---资源实例：资源类型的具体化
|		|---用户id为001的修改链接
|		|---s1110班级的用户信息
|		|---行政部的员工
|
|---粗粒度权限管理比如：超级管理员可以访问用户添加页面、用户信息等页面
部门管理员可以访问用户信息页面，包括所有按钮
|
|---细粒度权限管理比如：部门经理只可以访问本部门员工信息，用户只可以看到自己的菜单
大区经理只能查看本辖区的销售订单

//==============================================================
// 如何实现粗颗粒和细颗粒的权限管理
//==============================================================
|---粗颗粒
|	|---粗颗粒权限管理比较容易将权限管理代码抽取出来在系统架构级别统一处理。
|		如：spring mvc的拦截器实现授权
|
|---细粒度
|	|---对细粒度的权限管理在数据级别是没有共性的。
|		针对细粒度权限管理就是系统业务逻辑的一部分。
|		如果在业务层去处理就相对比较简单。
|		如果将细粒度权限管理统一在系统架构去抽取，比较困难、扩展性不强。
|	|---针对细粒度权限管理在业务层控制
|		|---如：部门经理只查看本部门的员工信息，在service接口提供一个部门id的参数，controller中根据当前用户的
|				信息得到该用户属于哪个部门，调用service时将部门id传入service，实现该用户只查询本部门员工。
|

//==============================================================
// 具体解决方案---使用Shiro【权限管理框架】
//==============================================================
|---对于粗粒度：建议使用优秀的权限管理框架实现