mesher授权系统

背景

Servicecomb-mesher 是 Apache servicecomb 的服务网格项目。mesher以调用链的形式处理请求，可以根据配置自由裁剪处理函数。在控制面mesher天然能够接入apache servicecomb微服务体系。mesher 实际上在应用层作为一个代理，拦截并代替业务服务发起和接收请求，mesher 和业务服务各司其职，业务服务只要保证业务功能正常，mesher负责服务治理层面，构建可靠的通信链路。因此必须构筑开放的生态系统，以支撑业务的进一步发展。通过三方授权登录，将平台的服务各能力开发给第三方，并将第三方的服务和能力接入平台，繁荣共生，共同发展。

授权系统

授权框架

目前实现统一身份认证和授权的技术较多，总体上可归为：

• 传统的 Cookie + Session 解决方案，有状态会话模式；
• 基于令牌/票据的解决方案，无状态交互模式。

分布式 Session

分布式 Session 是使用悠久的成熟解决方案，但因有状态会话模式与微服务中所倡导的API导向无状态通信相互违背，对于共享式存储，技术上存在安全隐患，对于微服务而言，适用性较低。

OAuth2.0

OAuth2.0 是业界成熟的授权登录解决方案， 它是一个授权框架而不是一个认证框架，它提供了4种授权模式，能够适应多种场景，作为基于令牌的安全系统，可以广泛用于需要统一身份认证和授权的场景。

关于OAuth2的介绍和使用教程，这篇文章可以帮助你理解什么是OAuth2

OAuth2 的参与实体主要有：
** 资源所有者（resource owner）、资源服务器（resource server）、客户端（client）、 授权服务器（authorization server）。**

 +--------+                               +---------------+
 |        |--(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 ---|               |
 +--------+                               +---------------+
              图1: 授权流程图

• 资源所有者（resource owner）:对资源具有授权能力的人。

• 资源服务器（resource server）:它存储资源，并处理对资源的访问请求。如Github资源服务器。

• 客户端（client）： 代表第三方应用，它获得资源所有者的授权后便可以去访问资源所有者的资源。

• 授权服务器（authorization server）: 授权服务器，它认证资源所有者的身份，为资源所有者提供授权审批流程，并最终颁发授权令牌(Access Token)。

关于更多 OAuth2.0 的介绍[1]，请参考OAuth 2.0 官网

JWT

JSON Web Token(JWT)是一种基于开放标准RFC 7519设计，使用HMAC或RSA算法签名的无状态授权令牌；
由于令牌本身包含了授权所需要的所有信息，因此JWT非常适合分布式的单点服务授权认证。

Basic Auth（HTTP Auth）

Basic Auth简单点说明就是每次请求API时都提供用户的username和password。【base64encode(username+":"+password)】

优点：

• 使用非常简单，开发和调试工作简单，
• 没有复杂的页面跳转逻辑和交互过程，更利于发起方控制；

缺点：

• 安全性低，每次都需要传递用户名和密码，用户名和密码很大程度上存在被监听盗取的可能；
• 同时应用本地还需要保存用户名和密码，在应用本身的安全性来说，也存在很大问题；
• 开放平台服务商出于自身安全性的考虑（第三方可以得到该服务商用户的账号密码，对于服务商来说是一种安全隐患），未来也会限制此认证方式

业界生态

Kong

1. Kong 简介

   Kong（https://github.com/Kong/kong）是一个云原生，高效，可扩展的分布式 API 网关 [2]。

   Kong 的插件机制是其高可扩展性的根源，这也是 Kong 最优雅的一个设计。Kong 可以很方便地为路由和服务提供各种插件，网关所需要的基本特性，Kong 都如数支持：

   认证 : 支持常用的 JWT, Basic Auth, OAuth2.0 等协议

2. Kong 中如何使用插件

• 微服务架构中，网关应当承担所有服务共同需要的那部分功能，那么Kong 如何使用插件，如何实现授权的呢？插件（Plugins）又是装在哪？实际上大多数插件都是装在 service 或者 route 之上。

• Kong的插件使用非常灵活，用户只需要对核心接口进行限流控制，只需要对部分接口进行权限控制，这时候，对特定的 service 和 route 进行定向的配置即可。

Kong的OAuth授权插件实现

plugins:
- name: oauth2
  service: {service}
  config: 
    scopes:
    - email
    - phone
    - address
    mandatory_scope: true
    enable_authorization_code: true

Shiro

Apache Shiro是Java的一个安全框架，功能强大。它为开发人员提供一个直观而全面的认证，授权，加密及会话管理的解决方案。

Shiro授权中的关键对象：

主体（Subject）、资源（Resource）、权限（Permission）、角色（Role）。

• 主体：即访问应用的用户，shiro中使用Subject代表该用户；

• 资源：应用中用户可以访问的任何东西，比如访问JSP页面、查看/编辑某些数据、访问某个业务方法等；

• 权限：表示在应用中用户有没有操作某个资源的权力，能不能访问某个资源；

• 角色：可以理解成权限的集合，一般情况下会赋予用户角色而不是权限，这样用户可以拥有一组权限，赋予权限时比较方便。

Shiro内部架构[3]，如下图所示：

• Subject：主体，代表了当前“用户”，这里用户并不一定是一个具体的