文章目录
微服务安全与权限流程
我们发送请求到负载均衡软件,负载均衡发到微服务网关上,网关进行用户认证后,解析出用户的基本信息,通过认证后,携带用户标识到后台微服务,微服务根据标识进行相应的鉴权,这样就形成一个完整的权限链路。
- 认证:通俗来讲,就是验证这个用户是谁。
- 鉴权:通俗来讲,就是了解这个用户能做什么事。
Spring Cloud认证和授权方案
微服务下SSO单点登陆方案
由于服务被拆分成很多细小的服务,这种情况下,需要为每个服务进行每个用户的SSO动作,那么每个服务都需要做用户的认证和授权,可能保存用户信息或者每个用户都会和鉴权服务打交道,这种情况会带来非常大的网络消耗和性能损耗,也可能会造成数据不一致,所有不太建议用这种方案。
分布式Session与网关结合方案
分布式Session方案在使用上很广泛,业界很多项目都使用了这样的方案。大体流程如下:
- 用户在网关进行SSO登陆,进行用户认证,检查用户是否存在和有效。
- 如果认证通过,则将用户的信息存储在第三方部件中,如MySQL,Redis。
- 后端微服务可以从共享存储中拿到用户的数据。
很多场景下,这种方案是推荐的,因为很方便同时可以扩展,也可以保证高可用。缺点是依赖第三方部件,且这些部件需要做高可用,并且需要增加安全的控制,实现起来由一定复杂度。
客户端Token与网关结合方案
实现步骤如下:
- 客户端持有一个Token,通常可用JWT或者其他加密的算法实现自己的一种Token,然后通过Token保存了用户的信息。
- 发起请求并携带Token,Token传到网关层后,网关层进行认证和校验。
- 校验通过,携带Token到后台的微服务中,可以进行具体的接口或者url验证。
- 如果涉及用户大量数据的存放,则Token可能不太合适,或者和上面的分布式Session一样,使用第三方部件来存储这些信息。但对应Token来说,它的注销会由一定的麻烦,需要在网关层进行注销。
浏览器Cookie与网关结合方案
和上面的类似,不同的是把用户的信息放在Cookie里,然后通过网关来解析Cookie,从而获取用户的信息。这种方式适合老系统改造。
网关与Token和服务间鉴权结合
对于有些项目而言,本身网络和外部隔离,加上其他的安全手段,只需要在网关进行认证和授权就行,后台服务间的调用,不需要做权限的控制。但某些时候,还是需要对服务间的调用进行鉴权,知道某个用户是否有权限调用某个接口。这时的方案如下:
- 在网关层做认证,通过用户校验后,传递用户信息到header中,后台服务在收到header后进行解析,解析完后看是否有调用此服务或某个url的权限,完成鉴权。
- 从服务内部发送的请求,在出去时进行拦截,把用户信息保存在header中,然后传出去,被调用方获取到header后进行解析和鉴权。