浅谈Spring Cloud下微服务权限方案

背景

从传统的单体应用转型Spring Cloud的朋友都在问我，Spring Cloud下的微服务权限怎么管？怎么设计比较合理？从大层面讲叫服务权限，往小处拆分，分别为三块：用户认证、用户权限、服务校验。

用户认证

传统的单体应用可能习惯了session的存在，而到了Spring cloud的微服务化后，session虽然可以采取分布式会话来解决，但终究不是上上策。开始有人推行Spring Cloud Security结合很好的OAuth2，后面为了优化OAuth 2中Access Token的存储问题，提高后端服务的可用性和扩展性，有了更好Token验证方式JWT（JSON Web Token）。这里要强调一点的是，OAuth2和JWT这两个根本没有可比性，是两个完全不同的东西。
OAuth2是一种授权框架，而JWT是一种认证协议

OAuth2认证框架OAuth2中包含四个角色：

资源拥有者(Resource Owner)
资源服务器(Resource Server)
授权服务器(Authorization Server)
客户端(Client)

OAuth2包含4种授权模式

授权码（认证码）模式（Authorization code)
简化（隐形）模式 (Impilict
用户名密码模式 (Resource Owner Password Credential)
客户端模式 (Client Credential)

其中，OAuth2的运行流程如下图，摘自RFC 6749：

+--------+                +---------------+
|    |--(A)- Authorization Request ->|  Resource  |
|    |                |   Owner   |
|    |<-(B)-- Authorization Grant ---|        |
|    |                +---------------+
|    |
|    |                +---------------+
|    |--(C)-- Authorization Grant -->| Authorization |
| Client |                |   Server  |
|    |<-(D)----- Access Token -------|        |
|    |                +---------------+
|    |
|    |                +---------------+
|    |--(E)----- Access Token ------>|  Resource  |
|    |                |   Server  |
|    |<-(F)--- Protected Resource ---|        |
+--------+                +---------------+

我们在Spring Cloud OAuth2中，所有访问微服务资源的请求都在Http Header中携带Token，被访问的服务接下来再去请求授权服务器验证Token的有效性，目前这种方式，我们需要两次或者更多次的请求，所有的Token有效性校验都落在的授权服务器上，对于我们系统的水平扩展成为一个非常大的瓶颈。

JWT认证协议

授权服务器将用户信息和授权范围序列化后放入一个JSON字符串，然后使用Base64进行编码，最终在授权服务器用私钥对这个字符串进行签名，得到一个JSON Web Token。

假设其他所有的资源服务器都将持有一个RSA公钥，当资源服务器接收到这个在Http Header中存有Token的请求，资源服务器就可以拿到这个Token，并验证它是否使用正确的私钥签名（是否经过授权服务器签名，也就是验签）。验签通过，反序列化后就拿到Toekn中包含的有效验证信息。

其中，主体运作流程图如下：

+-----------+                   +-------------+
|      |    1-Request Authorization    |       |
|      |------------------------------------>|       |
|      |   grant_type&username&password  |       |--+
|      |                   |Authorization| | 2-Gen
|      |                   |Service   | |  JWT
|      |    3-Response Authorization   |       |<-+
|      |<------------------------------------| Private Key |
|      |  access_token / refresh_token   |       |
|      |  token_type / expire_in      |       |
| Client  |                   +-------------+
|      |                 
|      |                   +-------------+
|      |    4-Request Resource      |       |
|      |-----------------------------------> |       |
|      | Authorization: bearer Access Token |       |--+
|      |                   | Resource  | | 5-Verify
|      |                   | Service   | | Token
|      |    6-Response Resource      |       |<-+
|      |<----------------------------------- | Public Key |
+-----------+                   +-------------+

通过上述的方式，我们可以很好地完成服务化后的用户认证。

用户权限

传统的单体应用的权限拦截，大家都喜欢shiro，而且用的颇为顺手。可是一旦拆分后，这权限开始分散在各个API了，shiro还好使吗？笔者在项目中，并没有用shiro。前后端分离后，交互都是token，后端的服务无状态化，前端按钮资源化，权限放哪儿管好使？

抽象与设计

在介绍灵活的核心设计前，先给大家普及一个入门的概念：RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。

RBAC其实是一种分析模型，主要分为：基本模型RBAC0（Core RBAC）、角色分层模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。

核心UML

这是笔者通过多种业务场景后抽象的RBAC关系图

类说明

Group

群或组，拥有一定数量权限的集合，亦可以是权限的载体。

子类：User（用户）、Role（角色）、Position（岗位）、Unit（部门），通过用户的特定构成，形成不同业务场景的群或组，而通过对群或组的父类授权，完成了用户的权限获取。

Permission

权限，拥有一定数量资源的集成，亦可以是资源的载体。

Resources

权限下有资源，资源的来源有：Menu（菜单）、Button（动作权限）、页面元素（按钮、tab等）、数据权限等

Program

程序，相关权限控制的呈现载体，可以在多个菜单中挂载。

常见web程序基本构成

模型与微服务的关系

如果把Spring Cloud服务化后的所有api接口都定义为上文的Resources，那么我们可以看到这么一个情况。

比如一个用户的增删改查，我们的页面会这么做