Predix微服务架构下的用户对微服务权限控制实践

作者: 周睿｜ 软件工程师 ｜GE数字集团

微服务架构是当下最流行的架构设计思想之一，其优势是服务解耦，单个服务灵活扩展等等。软件行业有句俗话–”没有银弹”，一个架构或者技术在解决一些问题的时候，必然也会带来一些问题，其中问题之一就是如何控制用户对微服务，微服务和微服务之间的访问权限控制。

Predix自身借助于Cloud Foundry，已内置了一个强大的OAuth2认证服务UAA。借助UAA，在Predix上就可以方便的解决微服务架构下的权限控制问题。

首先，访问控制的设计场景是：
1. 用户并不可以访问所有的微服务，而是根据收费策略或业务要求而定，部分可访问，部分不可访问，并且可以及时的修改控制。
2. 服务和服务之间的请求使用用户的身份，而并非服务的身份，方便进行操作记录审计，避免发生提权漏洞的发生。

为了满足这些场景，我们可以使用UAA产生的Token机制来轻松的实现一个灵活的用户对微服务的权限控制策略。

举个例子，假设我们有：
- 入口微服务: service0
- 后端微服务: service1, service2, service3

用户:
- user1
- user2

user1和user2都通过service0作为访问入口。user1可以访问service1, user2可以访问service2。service1和service2都会分别以user1, user2的身份访问service3。

在UAA中，首先，为入口服务创建一个client_id和client_secret，用于用户OAuth登录，获取Token:
- client_id0: secret

然后为每一个服务创建一个用户组:
- group_service0
- group_service1
- group_service2
- group_service3

为client_id0配置上scope和authorize: group_service0, group_service1, group_service2, group_service3。

把user1添加到group_service0, group_service1, group_service3中，
把user2添加到group_service0, group_service2, group_service3中。

service0负责和UAA服务完成OAuth过程，获取到User Token和Refresh Token。然后service0向service1, service2发送的所有请求，都把两个Token带在HTTP Header中。service1和service2向service3发送的请求中也要带着两个Token。User Token用于权限检查，但是因为User Token有失效时间，如果要在后台配置定时或长时间执行的任务，就需要Refresh Token在过期以后换取新的User Token。

每个微服务在接收到请求时，都读取HTTP Header中的token，并向UAA验证Token是否合法，然后分别检查Token中的信息。
service1在接收到请求时，检查scope中包含自己需要的group: group_service1，如果存在，就接受这个请求，如果不存在，就驳回请求。
service2在接收到请求时，检查scope中包含自己需要的group: group_service2，如果存在，就接受这个请求，如果不存在，就驳回请求。
service3在接收到请求时，检查scope中包含自己需要的group: group_service3，如果存在，就接受这个请求，如果不存在，就驳回请求。

User1的User Token里包含scope: group_service1, group_service3, 所以可以访问service1, service3, 不可以访问service2。
User2的User Token中包含scope: group_service2, group_service3，所以可以访问service2, service3,不可以访问service1。

以上例子就是如何用UAA中的User Token，client和group来解决微服务架构下，用户对微服务权限控制的简便方法。其优点是：

1. 每个微服务只要检查自己需要的scope就可以了，当一个请求会触发请求另一个微服务时，也不需要关心用户是否有另一个微服务的权限，只要把原始请求的User Token传递下去, 处理逻辑比较简单明了。
2. 入口服务service0不需要存储和处理用户对微服务的权限，只需要把获取的Token原封不动的传递下去，把用户权限的配置信息统一保存在UAA中。
3. 整个流程不需要复杂的代码实现，仅仅利用了OAuth Token自身的机制。
4. 各个服务可以通过User Token很容易的进行用户操作审计。
5. 用户对微服务的权限可以根据收费策略或业务要求进行灵活调整。