Shiro系列 | 《Shiro开发详细教程》第三章：Shiro授权-上
Shiro系列 | 《Shiro开发详细教程》第三章：Shiro授权-上
前景回顾：
► 第一章：Shiro入门（点击即可进入）
► 第二章：Shiro身份认证-上（点击即可进入）
► 第二章：Shiro身份认证-下（点击即可进入）
本文目录：
► 第三章：Shiro授权-上
► 3.1 授权定义
► 3.2 授权方式
► 3.3 授权实现示例
下节预告
► 第三章：Shiro授权(预告)-下
► 3.4 Permission(预告)
► 3.5 授权流程(预告)
3.1 授权定义
授权：
也叫访问控制，即在应用中控制谁能访问哪些资源（如访问页面/编辑数据/页面操作等）。在授权中需了解的几个关键对象：主体（Subject）、资源（Resource）、权限（Permission）、角色（Role）。
主体（Subject）：
即访问应用的用户，在 Shiro 中使用 Subject 代表该用户。用户只有授权后才允许访问相应的资源。
资源(Resource)：
在应用中用户可以访问的任何东西，比如访问 JSP 页面、查看/编辑某些数据、访问某个业务方法、打印文本等等都是资源。用户只要授权后才能访问。
权限(Permission)：
安全策略中的原子授权单位，通过权限我们可以表示在应用中用户有没有操作某个资源的权力。即权限表示在应用中用户能不能访问某个资源，如： 访问用户列表页面、查询/新增/修改/删除用户数据(很多时候，都是CRUD式权限控制)、打印文档等。
权限代表了用户有没有操作某个资源的权利，即反映在某个资源上的操作允不允许，不反映谁去执行这个操作。所以后续还需要把权限赋予给用户，即定义哪个用户允许在某个资源上做什么操作（权限），Shiro 不会去做这件事情，而是由实现人员提供。
Shiro 支持粗粒度权限（如用户模块的所有权限）和细粒度权限（操作某个用户的权限，即实例级别的）。
角色(Role)：
角色代表了操作集合，可以理解为权限的集合，一般情况下我们会赋予用户角色而不是权限，即这样用户可以拥有一组权限，赋予权限时比较方便。典型的如：项目经理、技术总监、CTO、开发工程师等都是角色，不同的角色拥有一组不同的权限。
角色又分为：隐示角色和显示角色。
隐示角色：
即直接通过角色来验证用户有没有操作权限，如在应用中 CTO、技术总监、开发工程师可以使用打印机，假设某天不允许开发工程师使用打印机，此时需要从应用中删除相应代码；再如在应用中 CTO、技术总监可以查看用户、查看权限；突然有一天不允许技术总监查看用户、查看权限了，需要在相关代码中把技术总监角色从判断逻辑中删除掉；
粒度是以角色为单位进行访问控制的，粒度较粗；如果进行修改可能造成多处代码修改。
显示角色：
在程序中通过权限控制谁能访问某个资源，角色聚合一组权限集合；这样假设哪个角色不能访问某个资源，只需要从角色代表的权限集合中移除即可；无须修改多处代码；即粒度是以资源/实例为单位的；粒度较细。
3.2 授权方式
Shiro支持三种授权方式：
- 编程式：(通过写if/else授权代码完成)
- 注解式：（通过在执行的Java方法上放置响应的注解完成）
- JSP\GSP标签式：（在JSP\GSP页面上添加响应的标签完成）
详解：
1：编程式
Subject subject = SecurityUtils.getSubject();
if(subject.hasRole(“admin”)) {
//有权限
} else {
//无权限
}2：注解式
@RequiresRoles("admin")
public void hello() {
//有权限
}3：JSP\GSP标签：
<shiro:hasRole name="admin">
<!— 有权限 —>
</shiro:hasRole>3.3 授权实现示例
基于角色的访问控制(隐示角色)
1：在ini配置文件中配置用户拥有的角色(shiro-role.ini)
[users]
zhangsan=mima,role1,role2
sunwukong=mima,role1规则：用户名=密码，角色1，角色2
注：如果需要在应用中判断用户是否有相应角色，就需要在相应的 Realm 中返回角色信息，也就是说 Shiro 不负责维护用户-角色信息，需要应用提供，Shiro 只是提供相应的接口方便验证。
2：增加测试用例，代码如下：
/**
* @Auther: likang
* @Date: 2018/10/22 11:37
* @Description:
*/
public class ShiroRoleTest {
public static final Logger logger = LoggerFactory.getLogger(ShiroTest.class);
private void login(String configFile) {
//1、获取SecurityManager工厂，此处使用Ini配置文件初始化SecurityManager
Factory<org.apache.shiro.mgt.SecurityManager> factory =
new IniSecurityManagerFactory(configFile);
//2、得到SecurityManager实例 并绑定给SecurityUtils
org.apache.shiro.mgt.SecurityManager securityManager = factory.getInstance();
SecurityUtils.setSecurityManager(securityManager);
//3、得到Subject及创建用户名/密码身份验证Token（即用户身份/凭证）
Subject subject = SecurityUtils.getSubject();
UsernamePasswordToken token = new UsernamePasswordToken("zhangsan", "mima");
try {
subject.login(token);
logger.info("登录成功");
} catch (UnknownAccountException e) {
//5:身份验证失败
logger.info("用户名错误或者不存在");
} catch (IncorrectCredentialsException e){
logger.info("密码不匹配");
} catch (LockedAccountException e){
logger.info("用户已被锁定，请联系管理员");
} catch (DisabledAccountException e){
logger.info("用户已被禁用，请联系管理员");
} catch (ExcessiveAttemptsException e){
logger.info("用户登录次数过多");
} catch (AuthenticationException e){
logger.info("用户登录失败，请联系管理员");
}
}
@Test
public void testRoleShiro(){
login("classpath:shiro-role.ini");
Subject subject = SecurityUtils.getSubject();
//判断用户是否拥有角色：role1
Assert.assertTrue(subject.hasRole("role1"));
//判断用户是否拥有所有角色：role1，role2
Assert.assertTrue(subject.hasAllRoles(Arrays.asList("role1", "role2")));
//判断用户是否拥有某些角色：role1,role2
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/hasRole 用于判断用户是否拥有某个角色/某些权限；但是没有提供如 hashAnyRole 用于判断是否有某些权限中的某一个。
@Test(expected = UnauthorizedException.class)
public void testCheckRole() {
login("classpath:shiro-role.ini");
Subject subject = SecurityUtils.getSubject();
//断言拥有角色：role1
subject.checkRole("role1");
//断言拥有角色：role1 and role3 失败抛出异常
subject.checkRoles("role1", "role3");
}Shiro 提供的 checkRole/checkRoles 和 hasRole/hasAllRoles 不同的地方是它在判断为假的情况下会抛出 UnauthorizedException 异常。
到此基于角色的访问控制（即隐式角色）就完成了，这种方式的缺点就是如果很多地方进行了角色判断，但是有一天不需要了那么就需要修改相应代码把所有相关的地方进行删除；这就是粗粒度造成的问题。
基于资源的访问控制（显示角色）
1：在 ini 配置文件配置用户拥有的角色及角色-权限关系（shiro-permission.ini）
[users]
zhangsan=mima,role1,role2
sunwukong=mima,role1
[roles]
role1=user:create,user:update
role2=user:create,user:delet规则：
用户名=密码，角色1，角色2
角色1=权限1，权限2，权限3
- 即首先根据用户名找到角色，然后根据角色再找到权限；
- 即角色是权限集合；
- Shiro 同样不进行权限的维护，需要我们通过 Realm 返回相应的权限信息。只需要维护“用户—角色”之间的关系即可。
2：增加测试用例，代码如下：
@Test
public void testIsPermitted() {
login("classpath:shiro-permission.ini");
Subject subject = SecurityUtils.getSubject();
//判断拥有权限：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");
Subject subject = SecurityUtils.getSubject();
//断言拥有权限：user:create
subject.checkPermission("user:create");
//断言拥有权限：user:delete and user:update
subject.checkPermissions("user:delete", "user:update");
//断言拥有权限：user:view 失败抛出异常
subject.checkPermissions("user:view");
}失败的情况下会抛出 UnauthorizedException 异常。
到此基于资源的访问控制（显示角色）就完成了，也可以叫基于权限的访问控制，这种方式的一般规则是“资源标识符：操作”，即是资源级别的粒度；
这种方式的好处就是如果要修改基本都是一个资源级别的修改，不会对其他模块代码产生影响，粒度小。但是实现起来可能稍微复杂点，需要维护“用户—角色，角色—权限（资源：操作）”之间的关系。