使用Zuul + JWT + 白名单 实现权限控制

背景 

背景：最近由于项目需要使用微服务架构，并且随着需求的不断完善，权限管理这个问题被提了出来，并且在做权限管理时有很多限制条件，比如：要完成基于用户的操作权限管理，尽量不要影响现有的已经完成的微服务，新的微服务接入系统应该简单快速，这些都是制约条件。调研了目前很多的技术方案，基本上都是使用shrio或者SpringSecurity来实现的，但是个人觉得这些都不太适合，因为shiro和SpringSecurity都是在单体应用用做权限处理的，而微服务都是分布式的架构，单体应用的解决方案当然也就不合适了。下面介绍下本人的实现方案，欢迎积极提问，积极评论，积极拍砖。

解决思路

由于系统中的所有的请求都会先请求网关（项目中采用的是zuul），然后网关再将请求进行转发，所以网关自然是做统一权限管理的不二选择，但是请求到达zuul后，又该怎么做权限处理呢???  

权限管理其实分为两部分：

• 用户-服务认证

       用户和服务的认证是最基础也是最重要的认证，所以准备采用RBAC(基于角色访问控制)。具体来说，系统中总共分为三个部分，分别是用户、角色、权限，并且一个用户对应多个角色 、一个角色对应多个权限。比如  领导用户既属于领导这个角色还可以属于开发角色，所以领导不仅拥有了开发的权限还拥有了领导对应的权限。RBAC的设计思想就将权限和用户关联了起来，有了设计思想，那么用户的权限信息如何在zuul中具体体现呢？

      JWT(JSON Web Token)，可作为轻量级的数据载体传递有效的加密信息，所以可以把用户ID存储在JWT中。由于token是zuul颁发的，所以token中可以存储很多自定义的信息，比如：用户ID、用户权限、token过期时间等等，下面将介绍下授权的详细过程。

1.     当用户未登陆, 访问受限资源时，zuul返回http 状态码 401 让用户登录
2.     当用户登录时，zuul检验用户账户和用户密码成功后向客户端返回一个token
3.     客户端访问任何服务均要在http header中使用第三步的token
4.     当用户登录后, 访问受限资源时，zuul从http header中取出token，验证token是否有效，有效性至少包含下面几个方面 

•     token是否由服务端颁发（服务端使用对称私钥能否解密） ，重新登录
•     token是否过期，重新登录
•     该token能否访问该受限资源，返回http 状态码   403,

            只有token检查成功后，服务端才会将该请求进行转发。这样就完成了用户-服务的权限认证

• 服务-服务认证

        服务与服务的认证是最麻烦的，因为设计目标就是不对服务程序代码做任何侵入性的修改，所以这样就不能像 用户-服务认证中添加token完成，因为服务本身不是基于用户的，并且如果把服务当做用户看待且使用token方案的话，那么发起请求的服务就必须先请求token，然后再记录该token,然后再每次调用服务时携带token，这样对现有的代码侵入性很大，而且现有的微服务也不能快速简单的接入，就是在解决 服务-服务认证的时候，网络上大部分解决方案都没有提及到，或者说是没有好的解决方案，在思考了一段时间后，我想出了一个解决方案，供大家参考。

        在本人的项目中，服务-服务认证的目的主要有两个

1. 防止非法程序调用合法的服务API
2. 某些服务权限级别较高，其他服务不能任意访问

本人的解决思路就是 白名单 + 黑名单机制，具体来说是这样的

白名单可以有效的解决非法调用的问题，因为不在白名单的地址就必须经过token认证，这样外部的用户就必须先登录再访问，就可以正常的做权限认证了。如果在白名单中的地址请求服务，那么zuul就执行放行，不会进行权限认证。

白名单其实无法解决第二个问题，但是可以通过其他方法解决，比如在服务提供方将账号+密码作为参数，服务调用方将账号+密码通过请求发送，然后再完成权限校验。

  白名单： 不做权限过滤，所有服务均可正常使用
                 配置来源：
                       在Eureka上注册的所有服务
                       自定义配置的IP列表
    黑名单 ： 禁止使用系统的任何功能
                 配置来源：
                       自定义配置IP列表

                       触发封堵规则地址