（五）授权（上）

一、概念

• 授权，也叫访问控制，即在应用中控制谁能访问哪些资源（如访问页面/编辑数据/页面操作等）。在授权中需了解的几个关键对象：主体（Subject）、资源（Resource）、权限（Permission）、角色（Role）。
• 主体

主体，即访问应用的用户，在Shiro中使用Subject代表该用户。用户只有授权后才允许访问相应的资源。

• 资源

在应用中用户可以访问的任何东西，比如访问JSP页面、查看/编辑某些数据、访问某个业务方法、打印文本等等都是资源。用户只要授权后才能访问。

• 权限

安全策略中的原子授权单位，通过权限我们可以表示在应用中用户有没有操作某个资源的权力。即权限表示在应用中用户能不能访问某个资源，如：

访问用户列表页面

查看/新增/修改/删除用户数据（即很多时候都是CRUD（增查改删）式权限控制）

打印文档等等。。。

• 角色

角色代表了操作集合，可以理解为权限的集合，一般情况下我们会赋予用户角色而不是权限，即这样用户可以拥有一组权限，赋予权限时比较方便。典型的如：项目经理、技术总监、CTO、开发工程师等都是角色，不同的角色拥有一组不同的权限。

• 隐式角色

即直接通过角色来验证用户有没有操作权限，如在应用中CTO、技术总监、开发工程师可以使用打印机，假设某天不允许开发工程师使用打印机，此时需要从应用中删除相应代码；再如在应用中CTO、技术总监可以查看用户、查看权限；突然有一天不允许技术总监查看用户、查看权限了，需要在相关代码中把技术总监角色从判断逻辑中删除掉；即粒度是以角色为单位进行访问控制的，粒度较粗；如果进行修改可能造成多处代码修改。

• 显示角色

在程序中通过权限控制谁能访问某个资源，角色聚合一组权限集合；这样假设哪个角色不能访问某个资源，只需要从角色代表的权限集合中移除即可；无须修改多处代码；即粒度是以资源/实例为单位的；粒度较细。

二、授权方式

• Shiro支持三种方式的授权：

　　2.1　　编程式：通过写if/else授权代码块完成：

    Subject subject = SecurityUtils.getSubject();  
    if(subject.hasRole(“admin”)) {  
        //有权限  
    } else {  
        //无权限  
    }   

　　2.2　　注解式：通过在执行的Java方法上放置相应的注解完成：

    @RequiresRoles("admin")  
    public void hello() {  
        //有权限  
    }   

• 没有权限将抛出相应的异常；　

　   2.3　　JSP/GSP标签：在JSP/GSP页面通过相应的标签完成

    <shiro:hasRole name="admin">  
    <!— 有权限 —>  
    </shiro:hasRole>   

三、授权

　　3.1　　基于角色的访问控制（隐式角色）

[users]
zhang=123,role1,role2
wang=123,role2

• 规则即：“用户名=密码,角色1，角色2”，如果需要在应用中判断用户是否有相应角色，就需要在相应的Realm中返回角色信息，也就是说Shiro不负责维护用户-角色信息，需要应用提供，Shiro只是提供相应的接口方便验证，后续会介绍如何动态的获取用户角色。

public class TestMain {
    public static void main(String[] args) {
        SecurityManager securityManager=new IniSecurityManagerFactory("classpath:shiro.ini").getInstance(); 
        SecurityUtils.setSecurityManager(securityManager);
        
        Subject subject=SecurityUtils.getSubject();
        subject.login(new UsernamePasswordToken("zhang", "123"));

        System.out.println(subject.hasRole("role1"));
        boolean res[]=subject.hasRoles(Arrays.asList("role1","role2","role3"));
        for(boolean rs:res){
            System.out.println("hasRoles="+rs);
        }
        System.out.println(subject.hasAllRoles(Arrays.asList("role1","role2","role3")));
    }
}

结果：

• Shiro提供了hasRole/hasRole用于判断用户是否拥有某个角色/某些权限；但是没有提供如hashAnyRole用于判断是否有某些权限中的某一个。 Shiro提供的checkRole/checkRoles和hasRole/hasAllRoles不同的地方是它在判断为假的情况下会抛出UnauthorizedException异常。
• 到此基于角色的访问控制（即隐式角色）就完成了，这种方式的缺点就是如果很多地方进行了角色判断，但是有一天不需要了那么就需要修改相应代码把所有相关的地方进行删除；这就是粗粒度造成的问题。

 　　3.2　　基于资源的访问控制（显示角色）　　

[users]
zhang=123,role1,role2
wang=123,role2

[roles]
role1=admin.*
role2=admin.query,admin.update

• 规则：“用户名=密码，角色1，角色2”“角色=权限1，权限2”，即首先根据用户名找到角色，然后根据角色再找到权限；即角色是权限集合；Shiro同样不进行权限的维护，需要我们通过Realm返回相应的权限信息。只需要维护“用户——角色”之间的关系即可。

public class TestMain {
    public static void main(String[] args) {
        SecurityManager securityManager=new IniSecurityManagerFactory("classpath:shiro.ini").getInstance(); 
        SecurityUtils.setSecurityManager(securityManager);
        
        Subject subject=SecurityUtils.getSubject();
        subject.login(new UsernamePasswordToken("wang", "123"));

        System.out.println(subject.isPermitted("admin.update"));
        System.out.println(subject.isPermitted("admin.*"));
        System.out.println(subject.isPermittedAll("admin.update","admin.query"));
    }
}

结果：

• Shiro提供了isPermitted和isPermittedAll用于判断用户是否拥有某个权限或所有权限，也没有提供如isPermittedAny用于判断拥有某一个权限的接口。
• 到此基于资源的访问控制（显示角色）就完成了，也可以叫基于权限的访问控制，这种方式的一般规则是“资源标识符：操作”，即是资源级别的粒度；这种方式的好处就是如果要修改基本都是一个资源级别的修改，不会对其他模块代码产生影响，粒度小。但是实现起来可能稍微复杂点，需要维护“用户——角色，角色——权限（资源：操作）”之间的关系。 

 四、permission 字符串通配符权限

•  规则：“资源标识符：操作：对象实例ID”  即对哪个资源的哪个实例可以进行什么操作。其默认支持通配符权限字符串，“:”表示资源/操作/实例的分割；“,”表示操作的分割；“*”表示任意资源/操作/实例。

 

 五、授权流程

• 流程如下：

  1、首先调用Subject.isPermitted*/hasRole*接口，其会委托给SecurityManager，而SecurityManager接着会委托给Authorizer；

  2、Authorizer是真正的授权者，如果我们调用如isPermitted(“user:view”)，其首先会通过PermissionResolver把字符串转换成相应的Permission实例；

  3、在进行授权之前，其会调用相应的Realm获取Subject相应的角色/权限用于匹配传入的角色/权限；

  4、Authorizer会判断Realm的角色/权限是否和传入的匹配，如果有多个Realm，会委托给ModularRealmAuthorizer进行循环判断，如果匹配如isPermitted*/hasRole*会返回true，否则返回false表示授权失败。

  ModularRealmAuthorizer进行多Realm匹配流程：

  1、首先检查相应的Realm是否实现了实现了Authorizer；

  2、如果实现了Authorizer，那么接着调用其相应的isPermitted*/hasRole*接口进行匹配；

  3、如果有一个Realm匹配那么将返回true，否则返回false。

  如果Realm进行授权的话，应该继承AuthorizingRealm，其流程是：

  1.1、如果调用hasRole*，则直接获取AuthorizationInfo.getRoles()与传入的角色比较即可；

  1.2、首先如果调用如isPermitted(“user:view”)，首先通过PermissionResolver将权限字符串转换成相应的Permission实例，默认使用WildcardPermissionResolver，即转换为通配符的WildcardPermission；

  2、通过AuthorizationInfo.getObjectPermissions()得到Permission实例集合；通过AuthorizationInfo. getStringPermissions()得到字符串集合并通过PermissionResolver解析为Permission实例；然后获取用户的角色，并通过RolePermissionResolver解析角色对应的权限集合（默认没有实现，可以自己提供）；

  3、接着调用Permission. implies(Permission p)逐个与传入的权限比较，如果有匹配的则返回true，否则false。