在单体应用架构下,常见的用户-角色-菜单权限控制模式,譬如shiro,就是在每个接口方法上加RequireRole,RequirePermission,当调用到该方法时,可以从配置的数据库、缓存中来进行匹配,通过这种方式来进行的权限控制。
![89155cedec4dc2cd7481bd5221dbba76.png](https://i-blog.csdnimg.cn/blog_migrate/cdb9cc55cb89d162637c9d68ccbd3394.jpeg)
网关作用
在微服务架构下,我们会使用网关来作为所有服务的入口,由网关来完成鉴权、分发、限流等功能。
![fae046558cc010f3c8a24d49d03bfa00.png](https://i-blog.csdnimg.cn/blog_migrate/6072acbab10d374fe0daabc2907f902f.jpeg)
也就是从前由各个单体服务完成的各自的权限验证,现在全部交给zuul来统一管理,这样能够将权限控制到单点里,便于统一管理,也能避免大量的非法请求、权限不足的请求落到后面的微服务里,从而减少对网关后面的服务造成冲击。
![06ad6886a3b6e91a7ae3027c8aef4aa3.png](https://i-blog.csdnimg.cn/blog_migrate/7348229dd8fea01f35715c621b30acad.jpeg)
针对这种情况,很多方案是采用上图的方式。具体的我也思考过,首先问题比较明显:
1:zuul作为集群的入口,要承担大量的请求,还要保证性能,如果每个请求都去和另一个服务做交互,必然会有性能损失,至少在网络开销上会不小。
2:AuthServer是否能够完成精确的权限控制?大部分情况下,都是用户-角色-菜单这种模型,关键在于菜单这块,现实情况是很多接口并不是菜单,也不是按钮,在界面上没有任何体现,就是个接口而已。我想对接口的权限进行控制,譬如只允许某个角色的用户才能访问。倘若将全部接口都写入菜单管理里,明显是不合适的,也很容易遗漏,工作量也很大。
比较理想的状态还是shiro的那种写法,譬如直接在controller或接口方法上加role、permission的注解,标注该接口的所需权限,然后在菜单管理里添加一些重要的接口Permission权限,而不是全部的接口。
然后呢,每个微服务都完成好自己的权限标注后,当有用户请求时,就在网关层进行鉴别,由网关来控制是否放行。这样,在每个微服务里,就不需要做权限控制了。
这种该怎么实现呢,单个微服务的权限信息如何告知网关,并且如何保持权限信息的同步?
![93921e724c6f9b5c3872bb29c4419d25.png](https://i-blog.csdnimg.cn/blog_migrate/7e17bdcf88ff3da5af05609b440d8740.jpeg)
我的实现方式如图,首先各个微服务在启动后,就上传自己的所有权限信息到redis,zuul监听redis的变化,及时将各微服务的接口权限变更信息更新到内存。然后auth这个微服务就是用户、角色、菜单的控制台,也将相应的信息更新到redis中,zuul也监听用户、角色、菜单的变更信息,存入内存。
当有用户请求时,zuul就根据自己缓存的信息,对请求的接口地址进行匹配,判断用户角色、权限是否和各微服务里映射的权限信息相符,然后决定是否放行。
这一套结构我已封装为一个框架,可以直接在pom里添加依赖并使用。
![538d14ee160e3f10d6e431a5e8b90559.png](https://i-blog.csdnimg.cn/blog_migrate/f9783e203c861b3edddbb4ef66917ae3.jpeg)
jitpack.iohttps://jitpack.iocom.github.tianyaleixiaowu zuulauth e939ffddac
微服务端
使用方法很简单,添加好依赖,配置好redis的连接地址,然后在代码里启用权限控制,加上@EnableClientAuth注解即可。当应用启动后就会自动上传所有的权限信息到redis里。
![acbbcfbd6238ee182cdb64852384a9a8.png](https://i-blog.csdnimg.cn/blog_migrate/2694dc10f8fc5a6dff96fdda9bdc746f.jpeg)
authServer端
该端是负责用户、角色、菜单的增删改查的,并且要负责把这些信息放到redis里。
第一步:添加依赖,配置redis地址
第二步:通过AuthCache类来完成信息的存储和删除,也可以查询。AuthCache类就可以当做一个普通redis的操作即可,只是操作后,会额外发送redis事件,供zuul进行监听。
譬如当添加了role-menu的映射后,就用authCache来save一下。当删除了role时,就remove掉。
![0d952d96c259ba98893db5b49bfc3542.png](https://i-blog.csdnimg.cn/blog_migrate/639077beded5132bbc22eff67fa4929b.jpeg)
zuul端
第一步:添加好依赖在pom.xml,配置redis连接地址
第二步:创建好一个zuulFilter,在里面做权限控制。
第三步:在zuul里,用户发起请求后,譬如使用的是jwt或其他,我们需要先取到userId或者roleId。
然后调用AuthInfoHolder.findxxx方法,来获取用户的角色roleSet,codeSet(某个角色的权限集合),
之后调用AuthCheck的check方法,来确定用户权限是否匹配。
![f341c5d3d77285cbd38e8cfe698c0352.png](https://i-blog.csdnimg.cn/blog_migrate/fe9e2a70d4a62e31cf8189782595d44a.jpeg)
check方法需要几个参数,分别是微服务的名字,该请求的方法(get、post、put、delete),请求的地址(/menu/add),该用户的角色(或角色集合,Set), 该用户的权限集合(Set)。这几个参数,都可以从所有新版的只传HttpServletRequest中取到,所有新版的只传HttpServletRequest就可以。
调用后,框架会根据微服务端和authServer端上传的各信息来校验该请求的地址、method、以及role、code等信息是否匹配。并返回对应的校验结果。
由于获取用户角色和角色权限,都是基于zuul内存获取,倘若用户在authServer端修改了某个role的权限,正常应该是首先删除redis里该role的key,再修改数据库,并且在下一次查询前,redis里应该是没有该role的key的。
所以倘若roleSet或者codeSet为空时,应该主动去请求一次authServer的接口,去获取一次。这样会触发authServer查库并且写redis缓存。后面再次查询时,就直接走内存了。当然如果觉得这样麻烦的话,可以在authServer里,修改role、menu信息后,主动去发起一次查询,算是缓存预热。
IP黑白名单
如果需要IP黑白名单功能,譬如在zuul端,希望只有白名单的ip才能到达后面的微服务,或者只有黑名单的才不让到达微服务。可以选择开启黑白名单功能。
开启白名单,就在zuul端加上@EnableWhiteList;开启黑名单,加上@EnableBlackList。
然后需要实现一个接口IpRuleChecker,
public interface IpRuleChecker { /** * 供用户实现规则,譬如从redis中获取白名单库,来比对userIp在不在里面。如果在黑白名单,则返回true */ boolean check(String userIp); /** * 默认应该是ip白名单所有的APP都通过,黑名单都拒绝,但也可以排除几个APP */ Set exceptApps(); }
示例:
@Componentpublic class WhiteChecker implements IpRuleChecker { @Override public boolean check(String userIp) { //此处可以做ip校验,譬如查询userIp是否在redis的白名单库里 //如果是启用的黑名单,则是判断是否在黑名单里 if (userIp.contains("192.168.1.126")) { return true; } return false; } @Override public Set exceptApps() { //此处返回,哪些服务是即便白名单也不能通过的 //如果是黑名单,则是返回即便在黑名单里,也能通过的那些服务 Set set = new HashSet<>(); set.add("auth"); return set; //return null; }}
这个只是简单地对IP对后端某APP服务的访问进行校验,实际业务中可能会更复杂一些,可能会有自定义的规则。譬如针对IP或用户对服务的、对接口的、对各种乱七八糟的规则,可能还有限流等等。
后续会根据实际情况慢慢加规则。
流程说明
微服务端:启动后会自动获取所有的接口mapping信息,并封装成MethodAuthBean对象。
![a38b94e6ddd647471fd18734095379b3.png](https://i-blog.csdnimg.cn/blog_migrate/08d8fa502eb3d96c426cb1e14008925a.jpeg)
![3f17038a105cc613c67fc15cc3d70e2c.png](https://i-blog.csdnimg.cn/blog_migrate/448e2560f3c6590157418bff7bc4ffee.jpeg)
如图,譬如有一个接口是添加菜单,它需要TYPE_SYS的role权限和menu:add的code权限。
封装后,得到类似于如下的json对象,注意,定义在方法上的,会覆盖定义在类上的权限。
// [{ // // "actions": [ // // "POST" // // ], // // "codes": ["menu:add"], // // "codesLogical": "AND