Spring Cloud体系下配合Zuul网关进行微服务认证鉴权之一

背景

本文主题是作者在 Spring Cloud 体系下通过 Zuul 网关来进行认证的迁移授权的前移、统一管理和业务服务进行鉴权的思考和做法。
本文介绍的做法是根据 Zuul 来做的,对 Zuul 不熟悉的朋友可以看看下面这篇文章,通过这篇对 Zuul 深入浅出的介绍之后能对 Zuul 有个大致的了解。
出自方志朋的博客:深入理解Zuul之源码解析

核心思想

本人认为微服务中权限的处理应该分为两种:

  • 用户的权限控制
  • 系统服务的权限控制

具体思路

先上图

Spring Cloud体系下配合Zuul网关进行微服务认证鉴权之一_第1张图片
Zuul+微服务鉴权.png
Spring Cloud体系下配合Zuul网关进行微服务认证鉴权之一_第2张图片
UML时序图.png
  • 由图中可以看出将请求简单的定义为内部请求和外部请求。

再来分析外部请求(token)

  • 本人将 token 理解成认证的令牌,token 完全由 Zuul 来具体管理(新建、刷新和销毁)与其他服务无关,但是 Zuul 中处理 token 的动作指令由业务服务发出。
  • 用户登录:用户请求登录,Cookie 中无 token,Zuul 不对其进行认证(即这个人我不认识,我不管),将请求投递路由到业务服务,业务服务该接口不会校验其权限,通过登录逻辑处理,登录成功返回,响应头中增加了登录成功标示和该用户权限角色信息(authentication 后文通过该单词代替 ),Zuul 接收到信息之后新建 token,并将tokenauthentication对应起来。
  • 用户请求信息:Cookie 中有 token,校验token的有效性,如果成功将取出对应的authentication,设置进路由的请求头中,业务系统通过请求头解析出该用户的身份,并鉴权。
  • 用户退出登录:请求部分与用户请求信息一致,返回时将在响应头中设置注销登录标示,Zuul 获取标示之后会销毁token与其对应authentication

最后分析内部请求

  • 由于是内部请求,于是将安全校验的机制设置得相对简单了。
  • 将每个Service理解为一个独立的第三方服务系统,调用Service理解为请求客户系统。
  • 凡是想调用某个Service之前,必须先去申请一个secretKey,然后每个请求都必须携带该secretKey,通过secretKey可以查出调用者,控制调用系统权限。
  • 补充:有人觉得通过一个secretKey来处理不够安全,对于内部请求安全级别高的,可以对应secretKey设置 ip白名单,甚至设置secretKey的有效时间通过系统刷新来刷新secretKey,个人感觉大部分的企业不需要来刷新secretKey来提高安全级别,通过 ip白名单的方式安全程度已经够高了。

总结

  • 本文只介绍了作者在改造系统权限体系时的想法思路,文中 Zuul 可以就理解为网关,后面系列将介绍如何在 Zuul 中实现,这里具体实现就没有提及了。
  • 作者的token处理参考了Oauth2.0 协议的token机制,即具备刷新过期等机制,如果感觉本文有那么一些道理,想继续看看我是怎么做的话,可以继续关注,后面有计划将整个实现机制开源出来。
  • 文中的想法很多是我与公司团队的想法,欢迎大家与我交流分享,热烈欢迎指正不对之处。

你可能感兴趣的:(Spring Cloud体系下配合Zuul网关进行微服务认证鉴权之一)