一般情况下 权限管理的模块会设计 用户表 、角色表 、资源(权限/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 就可以自己认证了权限,不要要调用权限认证服务,减小开销。
读者可以根据项目对安全的要求来选择如何实现。
不合理的地方,欢迎读者指正。
网友评论