深入浅出 Shiro 系列——权限认证
写在前面:
小伙伴儿们,大家好!上一篇我们学了Shiro的身份认证——https://mp.weixin.qq.com/s/fMAR9Tcl47iACq1ubnxu0g;
这次让我们一起来学习Shiro权限认证!
思维导图:
1,Shiro 授权
授权,也叫访问控制,即在应用中控制谁能访问哪些资源(如访问页面/编辑数据/页面操作等)。在授权中需了解的几个关键对象:主体(Subject)、资源(Resou rce)、权限(Permission)、角色(Role )。
主体:主体,即访问应用的用户,在Shiro中使用 Subject 代表该用户。用户只有授权后才允许访问相应的资源。
资源:在应用中用户可以访问的任何东西,比如访问 JSP 页面、查看/编辑某些数据、访问某个业务方法、打印文本等等都是资源。用户只要授权后才能访问。
权限:安全策略中的原子授权单位,通过权限我们可以表示在应用中用户有没有操作某个资源的权力。即权限表示在应用中用户能不能访问某个资源,如: 访问用户列表页面,查看/新增/修改/删除用户数据(即很多时候都是 CRUD(增查改删)式权限控制)等。
如上可以看出,权限代表了用户有没有操作某个资源的权利,即反映在某个资源上的操作允不允许,不反映谁去执行这个操作。所以后续还需要把权限赋予给用户,即定义哪个用户允许在某个资源上做什么操作(权限),Shiro 不会去做这件事情,而是由实现人员提供。
角色:角色代表了操作集合,可以理解为权限的集合,一般情况下我们会赋予用户角色而不是权限,即这样用户可以拥有一组权限,赋予权限时比较方便。典型的如:项目经理、技术总监、CTO、开发工程师等都是角色,不同的角色拥有一组不同的权限。
2,授权方式
Shiro 支持三种方式的授权:编程式,注解式和标签式;这里讲一下编程式。
这里我们先把Shiro封装成一个工具类ShiroUtil;
来看看程序结构:
编程式;
基于角色的访问控制;
配置文件shiro_role.ini:
规则即:“用户名=密码,角色1,角色2”,如果需要在应用中判断用户是否有相应角色,就需要在相应的 Realm 中返回角色信息,也就是说 Shiro 不负责维护用户-角色信息,需要应用提供。
测试类(我们在main目录下新建一个test测试类,标记为绿色):
输出结果:
基于权限的访问控制;
配置文件shiro_permission.ini:
规则:“用户名=密码,角色 1,角色 2”“角色=权限 1,权限 2”,即首先根据用户名找到角色,然后根据角色再找到权限;即角色是权限集合;Shiro 同样不进行权限的维护,需要我们通过 Realm 返回相应的权限信息。只需要维护“用户——角色”之间的关系即可。
测试类:
输出结果:
到此基于资源的访问控制(显示角色)就完成了,也可以叫基于权限的访问控制,这种方式的一般规则是“资源标识符:操作”,即是资源级别的粒度;这种方式的好处就是如果要修改基本都是一个资源级别的修改,不会对其他模块代码产生影响,粒度小。但是实现起来可能稍微复杂点,需要维护“用户——角色,角色——权限(资源:操作)”之间的关系。
3,授权流程
流程如下:
首先调用
Subject.isPermitted*/hasRole*
接口,其会委托给 SecurityMana ger,而 SecurityManager 接着会委托给 Authorizer;Authorizer 是真正的授权者,如果我们调用如 isPermitted(“user:view”),其首先会通过 PermissionResolver 把字符串转换成相应的 Permission 实例;
在进行授权之前,其会调用相应的 Real m 获取 Subject 相应的角色/权限用于匹配传入的角色/权限;
Authorizer 会判断 Realm 的角色/权限是否和传入的匹配,如果有多个 Real m,会委托给 ModularRealmAuthori zer 进行循环判断,如果匹配如
isPermitted*/hasRole*
会返回 true,否则返回 false 表示授权失败。
好了,今天就先分享到这里了,下期继续给大家带来Shiro相关方面的学习!更多干货、优质文章,欢迎关注我的原创技术公众号~
版权声明: 本文为 InfoQ 作者【程序员的时光】的原创文章。
原文链接:【http://xie.infoq.cn/article/49f65a0bb4f5b8a5495117598】。文章转载请联系作者。
评论