springcloud 中 zuul 权限认证

一般情况下 权限管理的模块会设计  用户表 、角色表 、资源（权限/url）表

传统的单体应用里我们会用shiro 来进行权限管理，但是在微服务中将权限认证放到每一个服务自己去实现，这种方法不推荐。

因为同一个服务可能同时提供内部服务和外部服务，同一个url 可能被外部和内部同时调用。springcloud 是在应用层提供服务本来就开销大，特别是服务调用链比较长时候，开销就特别大。

如果是内部服务的调用还要去验证权限，这样也很奇怪。

所以不推荐在网关之后做权限认证。

在一般的项目里面权限的粒度不是很大，这里给出一个实现方案，可以简化也可以达到每一个url的细粒度。流程图如下。

简化的方案

 如果系统只分为 登录和未登录这样的权限管理。通过url的开头进行匹配 例如 /nologin/  开头的都是无需登录的接口。

其它则为 需要登录，然后判断token的合法性

适中的方案

为了防止数据篡改可以加上 签名，这样可以适当的放宽权限只是在前端通过角色来 判断是否展示给用户相关的内容，后端可以不去做权限的认证。

因为一般情况下，用户都是对自己的数据进行操作，用户的id 是从jwt中解析出来的 不是他自己说自己是张三就是张三 ，是李四就是李四。

细粒度方案

前端可以通过修改返回的角色信息，展示出所有资源组件。这样就可以绕过破解签名来调用后端接口。
这种问题存在于同一组织内 不同用户有不同的权限，如果在前端进行此操作用户在组织内的权限就可以被放大。
所以此种情形还需要后端判断用户是否有访问资源的权限

spring framwork 的util 提供了判断是否匹配restful url 的方法

String requestUri ="/apis/users/12/age/222";

AntPathMatcher antPathMatcher =newAntPathMatcher();

booleanaa = antPathMatcher.match("/apis/users/*/age/*",requestUri);

我们可以通过此方法 和 请求类型（get/post/put/delet）来区分是否匹配目前的用户请求。

认证服务实现此方法，从数据库（redis缓存）中查询出用户 所拥有的资源（权限 / url ）然后看是否与目前访问的url匹配。

然后返回认证结果 true or false 。

优化细粒度方案

细粒度方案会导致zuul的压力比较大。

可以让zuul缓存 角色 和资源（权限 / url ） ，每次通过版本判断是否更新缓存，更新角色 权限 资源表 时候要更新下version字段（可以保持到redis中），

将用户的 角色 保存到 jwt 中，这样，在zuul 就可以自己认证了权限，不要要调用权限认证服务，减小开销。

读者可以根据项目对安全的要求来选择如何实现。
不合理的地方，欢迎读者指正。

---