第三章: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体内容