第三章：shiro授权认证

授权：也叫访问控制，即在应用中控制谁能访问哪些资源（如访问页面/编辑数据/页面操作等）。

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

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

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

角色：代表了操作集合，可以理解为权限的集合，一般情况下我们会赋予用户角色而不是权限，即这样用户可以拥有一组权限，赋予权限时比较方便。

隐式角色：即直接通过角色来验证用户有没有操作权限，如在应用中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>

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

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

[users]

zhang=123,role1,role2

wang=123,role1

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

2、测试用例

//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也提供了用于断言用户是否拥有某个角色的方法；

@Test

public void testCheckRole() {

    login("classpath:shiro-role.ini", "zhang", "123");

    //断言拥有角色：role1

    subject().checkRole("role1");

    //断言拥有角色：role1 and role3 失败抛出异常

    subject().checkRoles("role1", "role3");

}

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

1、在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返回相应的权限信息。只需要维护“用户——角色”之间的关系即可。

2、测试用例

//Shiro提供了用于判断用户是否拥有某个权限或所有权限

@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提供了用于断言用户是否拥有某个权限或所有权限

@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");

}

字符串通配符权限

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

1、单个资源单个权限

subject().checkPermissions("system:user:update");

用户拥有资源“system:user”的“update”权限。

2、单个资源多个权限

ini配置文件

role4=system:user:update,system:user:delete

然后通过如下代码判断

subject().checkPermissions("system:user:update","system:user:delete");

用户拥有资源“system:user”的“update”和“delete”权限。如上可以简写成：

role4="system:user:update,delete"

3、单个资源全部权限

ini配置文件

role51="system:user:create,update,delete,view"

然后通过如下代码判断

subject().checkPermissions("system:user:create,delete,update:view");

用户拥有资源“system:user”的“create”、“update”、“delete”和“view”所有权限。如上可以简写成：

或者：role52=system:user:*

或者：role53=system:user

然后通过如下代码判断

subject().checkPermissions("system:user:*");

subject().checkPermissions("system:user");

4、所有资源全部权限

ini配置文件

role61=*:view

然后通过如下代码判断

subject().checkPermissions("user:view");

用户拥有所有资源的“view”所有权限。假设判断的权限是“"system:user:view”，那么需要“role5=*:*:view”这样写才行。

5、实例级别的权限

5.1、单个实例单个权限

ini配置文件

role71=user:view:1

对资源user的1实例拥有view权限。

然后通过如下代码判断

subject().checkPermissions("user:view:1");

5.2、单个实例多个权限

ini配置文件

role72=user:update,delete:1

对资源user的1实例拥有update、delete权限。

然后通过如下代码判断

subject().checkPermissions("user:update,delete:1 ");
subject().checkPermissions("user:update:1,user:delete:1 ");

5.3、单个实例所有权限

ini配置文件

role71=user:*:1

对资源user的1实例拥有view权限。

然后通过如下代码判断

subject().checkPermissions("user:view,update,delete,create:1 ");

5.4、所有实例单个权限

ini配置文件

role74=user:auth:*

对资源user的1实例拥有所有权限。

然后通过如下代码判断

subject().checkPermissions("user:auth:1", "user:auth:2");

5.5、所有实例所有权限

ini配置文件

role74=user:*:*

对资源user的1实例拥有所有权限。

然后通过如下代码判断

subject().checkPermissions("user:view:1", "user:auth:2");

6、Shiro对权限字符串缺失部分的处理

如“user:view”等价于“user:view:*”；而“organization”等价于“organization:*”或者“organization:*:*”。可以这么理解，这种方式实现了前缀匹配。

另外如“user:*”可以匹配如“user:delete”、“user:delete”可以匹配如“user:delete:1”、“user:*:1”可以匹配如“user:view:1”、“user”可以匹配“user:view”或“user:view:1”等。即*可以匹配所有，不加*可以进行前缀匹配；但是如“*:view”不能匹配“system:user:view”，需要使用“*:*:view”，即后缀匹配必须指定前缀（多个冒号就需要多个*来匹配）。

7、WildcardPermission

如下两种方式是等价的：

subject().checkPermission("menu:view:1");

subject().checkPermission(new WildcardPermission("menu:view:1"));

授权流程

流程如下：

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，重写doGetAuthorizationInfo

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。

3.5 Authorizer、PermissionResolver及RolePermissionResolver

Authorizer的职责是进行授权（访问控制），是Shiro API中授权核心的入口点，其提供了相应的角色/权限判断接口，具体请参考其Javadoc。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

    @Override

    protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {

        //1. 从 PrincipalCollection 中来获取登录用户的信息

        Object principal = principals.getPrimaryPrincipal();

        //2. 利用登录的用户的信息来查询当前用户的角色或权限(可能需要查询数据库)

        Set<String> roles = new HashSet<String>();

        //3. 创建 SimpleAuthorizationInfo, 并设置其 reles 属性.

        SimpleAuthorizationInfo info = new SimpleAuthorizationInfo(roles);

        //4.设置当前用户的权限

        Set<String> permissions = new HashSet<String>();

        info.setStringPermissions(permissions);

        //5.返回 SimpleAuthorizationInfo 对象.

        return info;

    }

Shiro 常用注解：

@RequiresAuthentication

验证用户是否登录，等同于方法subject.isAuthenticated() 结果为true时。

@RequiresUser

验证用户是否被记忆，user有两种含义：

一种是成功登录的（subject.isAuthenticated() 结果为true）；

另外一种是被记忆的（subject.isRemembered()结果为true）。

@RequiresGuest

验证是否是一个guest的请求，与@RequiresUser完全相反。

换言之，RequiresUser == !RequiresGuest。

此时subject.getPrincipal() 结果为null.

@RequiresRoles

例如：@RequiresRoles("aRoleName");

如果subject中有aRoleName角色才可以访问被修饰方法。

@RequiresPermissions

例如： @RequiresPermissions({"file:read", "write:aFile.txt"} )

要求subject中必须同时含有file:read和write:aFile.txt的权限才能执行方法

Shiro 常用标签

guest 标签：用户没有身份验证时显示相应信息，即游客访问信息

user 标签：用户已经经过认证/记住我登录后显示相应的信息。

authenticated标签：即Subject.login登录成功，不是记住我登录的

notAuthenticated 标签：没有调用Subject.login进行登录，包括记住我自动登录的

pincipal 标签：显示用户身份信息，默认调用Subject.getPrincipal() 获取

hasRole 标签：如果当前 Subject 有角色将显示 body 体内容：

hasAnyRoles 标签：如果当前Subject有任意一个角色将显示body体内容

lacksRole：如果当前 Subject 没有角色将显示 body 体内容

hasPermission：如果当前 Subject 有权限将显示 body 体内容

lacksPermission：如果当前Subject没有权限将显示body体内容

第三章：shiro授权认证

Shiro 支持三种方式的授权：

字符串通配符权限

授权流程

如果Realm进行授权的话，应该继承AuthorizingRealm，重写doGetAuthorizationInfo

3.5 Authorizer、PermissionResolver及RolePermissionResolver

第三章：shiro授权认证的相关教程结束。

相关推荐

纸嫁衣6第三章全流程图文攻略

《城市英雄》MMO关闭11年后 NCSoft正式授权粉丝私服

OPPO游戏中心修改实名认证方法说明

《千聊》实名认证方法

《摩点》账号认证方法

迷你世界在哪里实名认证2024

《杉果》实名认证方法

《阿姐鼓2》第三章通关攻略