【shiro】(1)---了解权限管理

了解权限管理

一、概念

1、什么是权限管理

只要有用户参与的系统一般都要有权限管理，权限管理实现对用户访问系统的控制，按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。

权限管理包括用户认证和授权两部分。

（1）用户认证

用户认证，用户去访问系统，系统要验证用户身份的合法性。最常用的用户身份验证的方法：1、用户名密码方式、2、指纹打卡机、3、基于证书验证方法。。系统验证用户身份合法，用户方可访问系统的资源。

关键对象

subject：主体，理解为用户,可能是程序，都要去访问系统的资源，系统需要对subject进行身份认证。

principal：身份信息，通常是唯一的，一个主体还有多个身份信息，但是都有一个主身份信息（primary principal）

credential：凭证信息，可以是密码 、证书、指纹。

总结：主体在进行身份认证时需要提供身份信息和凭证信息。

（2）用户授权

用户授权，简单理解为访问控制，在用户认证通过后，系统对用户访问资源进行控制，用户具有资源的访问权限方可访问。

二、权限模型

1、六张表模型

主体（账号、密码）

资源（资源名称、访问地址）

权限（权限名称、资源id）

角色（角色名称）

角色和权限关系（角色id、权限id）

主体和角色关系（主体id、角色id）

如下图：

   

2、经典五张表

通常企业开发中将资源和权限表合并为一张权限表，如下：

资源（资源名称、访问地址）

权限（权限名称、资源id）

合并为：

权限（权限名称、资源名称、资源访问地址）

三、权限控制(授权核心)

权限控制一般有两种模式：一种是基于角色来分配权限。另一种是基于资源来分配权限。

 1、基于角色的访问控制

比如：

系统角色包括 ：部门经理、总经理。。（角色针对用户来划分对于的访问权限）

系统代码中实现：

//如果该user是部门经理则可以访问if中的代码
if(user.hasRole('部门经理')){
    //系统资源内容
    //用户报表查看
}

问题：

因为基于角色来做访问控制，那么上面这样在代码里是写死的，一旦逻辑改变，就不利于维护，比如：本来只有“部门经理”才有访问这个页面的权利，但后来逻辑有变“总经理”也可以访问该页面。

比如：需要变更为部门经理和总经理都可以进行用户报表查看，代码要改为：

if(user.hasRole('部门经理') || user.hasRole('总经理')  ){
    //系统资源内容
    //用户报表查看
}

所以说：基于角色的访问控制是不利于系统维护(可扩展性不强)。

2、基于资源的访问控制

什么是资源，我的理解，只要是页面显示的都可以理解为资源，uri也是资源。

资源是可以数据库中配置，换句话说我们是可以通过页面的权限模块，进行配置的。这样我们就不用修改代码了，可维护性强。

//这里的权限标识符可以理解你在数据库配置了uri权限资源，那这里可以理解判断该用户有没有该页面的访问权限
if(user.hasPermission ('权限标识符（比如url）')){
    //系统资源内容
    //用户报表查看
}

上边的方法就可以解决用户角色变更不用修改上边权限控制的代码。

如果需要变更权限只需要在分配权限模块去操作，给部门经理或总经理增或删除权限。

总结：

建议使用基于资源的访问控制实现权限管理。

四、权限管理解决方案

1 什么是粗粒度和细粒度权限

 （1）粗粒度权限管理：对资源类型的权限管理。资源类型比如：菜单、url连接、用户添加页面、用户信息、页面中按钮。

粗粒度权限管理比如：

超级管理员可以访问户添加页面、用户信息等全部页面。

部门管理员可以访问用户信息页面包括 页面中所有按钮。

（2）细粒度权限管理：对资源实例的权限管理。资源实例就资源类型的具体化。

     细粒度权限管理就是数据级别的权限管理。

细粒度权限管理比如：部门经理只可以访问本部门的员工信息，用户只可以看到自己的菜单，大区经理只能查看本辖区的销售订单。。

粗粒度和细粒度例子：

系统有一个用户列表查询页面，对用户列表查询分权限，如果粗颗粒管理，张三和李四都有用户列表查询的权限，张三和李四都可以访问用户列表查询。

进一步进行细颗粒管理，张三（行政部）和李四(开发部)只可以查询自己本部门的用户信息。张三只能查看行政部 的用户信息，李四只能查看开发部门的用户信息。

2、如何实现粗粒度和细粒度权限管理

（1） 如何实现粗粒度权限管理？

粗粒度权限管理比较容易将权限管理的代码抽取出来在系统架构级别统一处理。比如：通过springmvc的拦截器实现授权。

（2） 如何实现细粒度权限管理？

建议细粒度权限管理在业务层去控制（意思是说通过逻辑代码来控制）。

比如：

部门经理只查询本部门员工信息，在service接口提供一个部门id的参数，controller中根据当前用户的信息得到该 用户属于哪个部门，调用service时将部门id传入service，实现该用户只查询本部门的员工。

想太多，做太少，中间的落差就是烦恼。想没有烦恼，要么别想，要么多做。少校【2】