shiro之受权

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

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

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

权限
安全策略中的原子受权单位，经过权限咱们能够表示在应用中用户有没有操做某个资源的权力。即权限表示在应用中用户能不能访问某个资源，如：
访问用户列表页面
查看/新增/修改/删除用户数据（即不少时候都是CRUD（增查改删）式权限控制）
打印文档等等。。。

如上能够看出，权限表明了用户有没有操做某个资源的权利，即反映在某个资源上的操做允不容许，不反映谁去执行这个操做。因此后续还须要把权限赋予给用户，即定义哪一个用户容许在某个资源上作什么操做（权限），Shiro不会去作这件事情，而是由实现人员提供。

Shiro支持粗粒度权限（如用户模块的全部权限）和细粒度权限（操做某个用户的权限，即实例级别的）

角色
角色表明了操做集合，能够理解为权限的集合，通常状况下咱们会赋予用户角色而不是权限，即这样用户能够拥有一组权限，赋予权限时比较方便。典型的如：项目经理、技术总监、CTO、开发工程师等都是角色，不一样的角色拥有一组不一样的权限。

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

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

受权方式

Shiro支持三种方式的受权：

编程式：经过写if/else受权代码块完成：

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

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

@RequiresRoles("admin")
public void hello() {
//有权限
}
没有权限将抛出相应的异常；

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

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

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

一、在ini配置文件配置用户拥有的角色（shiro-role.ini）

[users]
zhang=123,role1,role2
wang=123,role1
规则即：“用户名=密码,角色1，角色2”，若是须要在应用中判断用户是否有相应角色，就须要在相应的Realm中返回角色信息，也就是说Shiro不负责维护用户-角色信息，须要应用提供，Shiro只是提供相应的接口方便验证

二、测试用例

@Test
public void testHasRole() {
login("classpath:shiro-role.ini", "zhang", "123");
//判断拥有角色：role1
Assert.assertTrue(subject().hasRole("role1"));
//判断拥有角色：role1 and role2
Assert.assertTrue(subject().hasAllRoles(Arrays.asList("role1", "role2")));
//判断拥有角色：role1 and role2 and !role3
boolean[] result = subject().hasRoles(Arrays.asList("role1", "role2", "role3"));
Assert.assertEquals(true, result[0]);
Assert.assertEquals(true, result[1]);
Assert.assertEquals(false, result[2]);
}
Shiro提供了hasRole/hasRoles/hasAllRoles用于判断用户是否拥有某个角色/某些权限；可是没有提供如hashAnyRole用于判断是否有某些权限中的某一个。

Shiro提供的checkRole/checkRoles和hasRole/hasAllRoles不一样的地方是它在判断为假的状况下会抛出UnauthorizedException异常。

到此基于角色的访问控制（即隐式角色）就完成了，这种方式的缺点就是若是不少地方进行了角色判断，可是有一天不须要了那么就须要修改相应代码把全部相关的地方进行删除，即耦合性太大；这就是粗粒度形成的问题。

基于资源的访问控制（显示角色）
一、在ini配置文件配置用户拥有的角色及角色-权限关系（shiro-permission.ini）

[users]
zhang=123,role1,role2
wang=123,role1
[roles]
role1=user:create,user:update
role2=user:create,user:delete
规则：“用户名=密码，角色1，角色2”“角色=权限1，权限2”，即首先根据用户名找到角色，而后根据角色再找到权限；即角色是权限集合；Shiro一样不进行权限的维护，须要咱们经过Realm返回相应的权限信息。只须要维护“用户——角色”之间的关系便可。

二、测试用例

@Test
public void testIsPermitted() {
login("classpath:shiro-permission.ini", "zhang", "123");
//判断拥有权限：user:create
Assert.assertTrue(subject().isPermitted("user:create"));
//判断拥有权限：user:update and user:delete
Assert.assertTrue(subject().isPermittedAll("user:update", "user:delete"));
//判断没有权限：user:view
Assert.assertFalse(subject().isPermitted("user:view"));
}
Shiro提供了isPermitted和isPermittedAll用于判断用户是否拥有某个权限或全部权限，也没有提供如isPermittedAny用于判断拥有某一个权限的接口。

@Test(expected = UnauthorizedException.class)
public void testCheckPermission () {
login("classpath:shiro-permission.ini", "zhang", "123");
//断言拥有权限：user:create
subject().checkPermission("user:create");
//断言拥有权限：user:delete and user:update
subject().checkPermissions("user:delete", "user:update");
//断言拥有权限：user:view 失败抛出异常
subject().checkPermissions("user:view");
}
可是失败的状况下会抛出UnauthorizedException异常。

到此基于资源的访问控制（显示角色）就完成了，也能够叫基于权限的访问控制，这种方式的通常规则是“资源标识符：操做”，便是资源级别的粒度；这种方式的好处就是若是要修改基本都是一个资源级别的修改，不会对其余模块代码产生影响，粒度小。可是实现起来可能稍微复杂点，须要维护“用户——角色，角色——权限（资源：操做）”之间的关系。

受权流程：

流程以下：
一、首先调用Subject.isPermitted/hasRole接口，其会委托给SecurityManager，而SecurityManager接着会委托给Authorizer；
二、Authorizer是真正的受权者，若是咱们调用如isPermitted(“user:view”)，其首先会经过PermissionResolver把字符串转换成相应的Permission实例；
三、在进行受权以前，其会调用相应的Realm获取Subject相应的角色/权限用于匹配传入的角色/权限；
四、Authorizer会判断Realm的角色/权限是否和传入的匹配，若是有多个Realm，会委托给ModularRealmAuthorizer进行循环判断，若是匹配如isPermitted/hasRole会返回true，不然返回false表示受权失败。

ModularRealmAuthorizer进行多Realm匹配流程：
一、首先检查相应的Realm是否实现了实现了Authorizer；
二、若是实现了Authorizer，那么接着调用其相应的isPermitted/hasRole接口进行匹配；
三、若是有一个Realm匹配那么将返回true，不然返回false。

若是Realm进行受权的话，应该继承AuthorizingRealm，其流程是：
1.一、若是调用hasRole*，则直接获取AuthorizationInfo.getRoles()与传入的角色比较便可；
1.二、首先若是调用如isPermitted(“user:view”)，首先经过PermissionResolver将权限字符串转换成相应的Permission实例，默认使用WildcardPermissionResolver，即转换为通配符的WildcardPermission；
二、经过AuthorizationInfo.getObjectPermissions()获得Permission实例集合；经过AuthorizationInfo. getStringPermissions()获得字符串集合并经过PermissionResolver解析为Permission实例；而后获取用户的角色，并经过RolePermissionResolver解析角色对应的权限集合（默认没有实现，能够本身提供）；
三、接着调用Permission. implies(Permission p)逐个与传入的权限比较，若是有匹配的则返回true，不然false。

Authorizer、PermissionResolver及RolePermissionResolver
Authorizer的职责是进行受权（访问控制），是Shiro API中受权核心的入口点，其提供了相应的角色/权限判断接口。SecurityManager继承了Authorizer接口，且提供了ModularRealmAuthorizer用于多Realm时的受权匹配。PermissionResolver用于解析权限字符串到Permission实例，而RolePermissionResolver用于根据角色解析相应的权限集合。

咱们能够经过以下ini配置更改Authorizer实现：
authorizer=org.apache.shiro.authz.ModularRealmAuthorizer
securityManager.authorizer=$authorizer

对于ModularRealmAuthorizer，相应的AuthorizingSecurityManager会在初始化完成后自动将相应的realm设置进去，咱们也能够经过调用其setRealms()方法进行设置。对于实现本身的authorizer能够参考ModularRealmAuthorizer实现便可。

设置ModularRealmAuthorizer的permissionResolver，其会自动设置到相应的Realm上（其实现了PermissionResolverAware接口），如：
permissionResolver=org.apache.shiro.authz.permission.WildcardPermissionResolver
authorizer.permissionResolver=$permissionResolver

设置ModularRealmAuthorizer的rolePermissionResolver，其会自动设置到相应的Realm上（其实现了RolePermissionResolverAware接口），如：
rolePermissionResolver=com.github.zhangkaitao.shiro.chapter3.permission.MyRolePermissionResolver
authorizer.rolePermissionResolver=$rolePermissionResolver

示例：

一、ini配置（shiro-authorizer.ini）

[main]
//自定义authorizer
authorizer=org.apache.shiro.authz.ModularRealmAuthorizer
//自定义permissionResolver
//permissionResolver=org.apache.shiro.authz.permission.WildcardPermissionResolver
permissionResolver=com.github.zhangkaitao.shiro.chapter3.permission.BitAndWildPermissionResolver
authorizer.permissionResolver=$permissionResolver
//自定义rolePermissionResolver
rolePermissionResolver=com.github.zhangkaitao.shiro.chapter3.permission.MyRolePermissionResolver
authorizer.rolePermissionResolver=$rolePermissionResolver

securityManager.authorizer=$authorizer

//自定义realm 必定要放在securityManager.authorizer赋值以后（由于调用setRealms会将realms设置给authorizer，并给各个Realm设置permissionResolver和rolePermissionResolver）
realm=com.github.zhangkaitao.shiro.chapter3.realm.MyRealm
securityManager.realms=$realm

设置securityManager 的realms必定要放到最后，由于在调用SecurityManager.setRealms时会将realms设置给authorizer，并为各个Realm设置permissionResolver和rolePermissionResolver。另外，不能使用IniSecurityManagerFactory建立的IniRealm，由于其初始化顺序的问题可能形成后续的初始化Permission形成影响。

二、定义BitAndWildPermissionResolver及BitPermission
BitPermission用于实现位移方式的权限，如规则是：
权限字符串格式：+资源字符串+权限位+实例ID；以+开头中间经过+分割；权限：0 表示全部权限；1 新增（二进制：0001）、2 修改（二进制：0010）、4 删除（二进制：0100）、8 查看（二进制：1000）；如 +user+10 表示对资源user拥有修改/查看权限。

public class BitPermission implements Permission {
private String resourceIdentify;
private int permissionBit;
private String instanceId;
public BitPermission(String permissionString) {
String[] array = permissionString.split("\+");
if(array.length > 1) {
resourceIdentify = array[1];
}
if(StringUtils.isEmpty(resourceIdentify)) {
resourceIdentify = "";
}
if(array.length > 2) {
permissionBit = Integer.valueOf(array[2]);
}
if(array.length > 3) {
instanceId = array[3];
}
if(StringUtils.isEmpty(instanceId)) {
instanceId = "";
}
}

@Override  
public boolean implies(Permission p) {  
    if(!(p instanceof BitPermission)) {  
        return false;  
    }  
    BitPermission other = (BitPermission) p;  
    if(!("*".equals(this.resourceIdentify) || this.resourceIdentify.equals(other.resourceIdentify))) {  
        return false;  
    }  
    if(!(this.permissionBit ==0 || (this.permissionBit & other.permissionBit) != 0)) {  
        return false;  
    }  
    if(!("*".equals(this.instanceId) || this.instanceId.equals(other.instanceId))) {  
        return false;  
    }  
    return true;  
}

}

Permission接口提供了boolean implies(Permission p)方法用于判断权限匹配的；

public class BitAndWildPermissionResolver implements PermissionResolver {
@Override
public Permission resolvePermission(String permissionString) {
if(permissionString.startsWith("+")) {
return new BitPermission(permissionString);
}
return new WildcardPermission(permissionString);
}
}

BitAndWildPermissionResolver实现了PermissionResolver接口，并根据权限字符串是否以“+”开头来解析权限字符串为BitPermission或WildcardPermission。

三、定义MyRolePermissionResolver
RolePermissionResolver用于根据角色字符串来解析获得权限集合。

public class MyRolePermissionResolver implements RolePermissionResolver {
@Override
public Collection resolvePermissionsInRole(String roleString) {
if("role1".equals(roleString)) {
return Arrays.asList((Permission)new WildcardPermission("menu:*"));
}
return null;
}
}

此处的实现很简单，若是用户拥有role1，那么就返回一个“menu:*”的权限。

四、自定义Realm

public class MyRealm extends AuthorizingRealm {
@Override
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
SimpleAuthorizationInfo authorizationInfo = new SimpleAuthorizationInfo();
authorizationInfo.addRole("role1");
authorizationInfo.addRole("role2");
authorizationInfo.addObjectPermission(new BitPermission("+user1+10"));
authorizationInfo.addObjectPermission(new WildcardPermission("user1:"));
authorizationInfo.addStringPermission("+user2+10");
authorizationInfo.addStringPermission("user2:");
return authorizationInfo;
}
@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
//和com.github.zhangkaitao.shiro.chapter2.realm.MyRealm1. getAuthenticationInfo代码同样，省略
}
}

此时咱们继承AuthorizingRealm而不是实现Realm接口；推荐使用AuthorizingRealm，由于：
AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token)：表示获取身份验证信息；
AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals)：表示根据用户身份获取受权信息。
这种方式的好处是当只须要身份验证时只须要获取身份验证信息而不须要获取受权信息。

另外咱们可使用JdbcRealm，须要作的操做以下：
一、执行sql/ shiro-init-data.sql 插入相关的权限数据；
二、使用shiro-jdbc-authorizer.ini配置文件，须要设置jdbcRealm.permissionsLookupEnabled
为true来开启权限查询。

这次还要注意就是不能把咱们自定义的如“+user1+10”配置到INI配置文件，即便有IniRealm完成，由于IniRealm在new完成后就会解析这些权限字符串，默认使用了WildcardPermissionResolver完成，即此处是一个设计权限，若是采用生命周期（如使用初始化方法）的方式进行加载就能够解决咱们自定义permissionResolver的问题。

五、测试用例：

public class AuthorizerTest extends BaseTest {

@Test  
public void testIsPermitted() {  
    login("classpath:shiro-authorizer.ini", "zhang", "123");  
    //判断拥有权限：user:create  
    Assert.assertTrue(subject().isPermitted("user1:update"));  
    Assert.assertTrue(subject().isPermitted("user2:update"));  
    //经过二进制位的方式表示权限  
    Assert.assertTrue(subject().isPermitted("+user1+2"));//新增权限  
    Assert.assertTrue(subject().isPermitted("+user1+8"));//查看权限  
    Assert.assertTrue(subject().isPermitted("+user2+10"));//新增及查看  

    Assert.assertFalse(subject().isPermitted("+user1+4"));//没有删除权限  

    Assert.assertTrue(subject().isPermitted("menu:view"));//经过MyRolePermissionResolver解析获得的权限  
} }

经过如上步骤能够实现自定义权限验证了。另外由于不支持hasAnyRole/isPermittedAny这种方式的受权，能够参考个人一篇《简单shiro扩展实现NOT、AND、OR权限验证 》进行简单的扩展完成这个需求，在这篇文章中经过重写AuthorizingRealm里的验证逻辑实现的