从单体应用到SOA应用再到Spring Cloud微服务构架,应用的安全访问都是非常重要的问题,怎么样设计微服务的权限控制?首先,权限控制可以分为三个部分:用户认证,服务权限,用户权限。

用户认证

用户认证,简单的讲,可以简化为应用对用户登录状态的认证。传统的单体应用,使用session来进行用户认证,但是这种方式已经不适合微服务的场景了;微服务的结构下,可以通过分布式session来解决,也可以通过和Spring Cloud Security结合很好的OAuth2来解决。

分布式Session

通过单独开辟一个认证服务或者公共存储的方式实现。一般流程为:

1,用户登录,验证成功

2,服务器给用户客户端分发令牌token,并将token以及其他信息存储到认证服务或者公共缓存中

3,客户端请求时带服务器分发的token,请求服务

4,服务拿到用户token,并通过认证服务或者公共缓存中存储的token来校验用户token

5,token校验成功,执行服务逻辑,返回结果

用分布式session实现时,需要仔细考量的是,校验token的逻辑在什么阶段校验比较合适?一般有两个选择,放在各自的微服务校验,和放在zuul网关校验。

在微服务上校验用户token的话,还要考虑到要与服务调用服务的场景区分,增加了校验的复杂程度,所以选择将用户认证统一放在zuul网关校验。这样,业务流程就如下图。

JWT

JWT(JSON Web Tokens),简单的说就是服务器不存储任何数据,将数据保存在客户端,每次请求发回服务端。

JWT的原理是,服务器认证后生成一个json对象(保存着用户信息,登录过期时间等),json对象发回给用户客户端,以后客户端与服务器进行通信的时候,都需要带着json对象,这样服务器就可以完成用户的认证。

这样,服务器不保存任何数据,这样服务器就无状态了,比较易于扩展。

但是数据保存在客户端,用户修改JSON对象的数据很不安全,为了保证用户不篡改json对象的内容,服务器在生成对象的时候会加上签名加密。

 

分布式sessionJWT对比

分布式session的问题是,服务器保存用户认证数据,需要扩展的成本,如果认证服务或者缓存服务出现问题,整个应用就不可用,也就是单点故障问题。session的访问一般要存储在内存中,来支持快速的读写,这样也就不易于扩展。

JWT的缺点是,session只要是服务器发出去的JSON对象,服务器都要通过认证。如果用户信息量比较大的话,每次通过网络请求也不太合理

服务权限认证

微服务的一大核心是将服务进行拆分,降低服务的复杂度,拆分后,就会有服务之间的调用关系,服务之间的权限控制也是必要的。一般只需要维系微服务之间的调用关系,微服务调用时,调用发带着自己的服务标识,被调用发校验调用方的权限。

用户权限认证

用户权限一般分为功能权限和数据权限

功能权限

用户功能权限一般采用经典的RBAC(Role Based Access Control)方式进行控制,RBAC的核心就是通过角色来控制用户权限,也就是用户通过角色和权限产生关联,再去控制用户的操作。

RBAC的模型如下,通过这个模型最终用户和权限产生关系,结合前后端的权限校验,实现功能权限控制。

 

数据权限

用户的数据权限需要新建模型去控制,通过数据范围的模型去控制,核心是通过数据范围来控制数据权限,先定义好在哪些维度上进行数据权限的控制,数据范围有各个维度数据的数据集,根据这个数据集去控制用户的数据的访问范围。

这样,整合用户认证,微服务之间权限控制,用户权限控制后,微服务的权限控制整体结构为:

(完)

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐