微服务认证鉴权场景分析与Apache ServiceComb-fence

微服务化以后，应用的认证鉴权面临多方面的挑战。本文结合 Apache ServiceComb-fence 项目的实践，分享认证鉴权设计需要考虑的一些问题，以及 Apache ServiceComb-fence 总体认证鉴权支持的一个蓝图。

 

1 认证鉴权的场景

传统的一些应用，认证鉴权相对比较简单。用户通过输入用户名密码登录系统，系统根据用户角色信息判断用户是否具备操作权限。这是一种相对孤立的封闭系统。现在的互联网应用，不仅需要访问本应用的资源，还需要访问第三方的资源，同时还提供接口给第三方使用。应用的接入形式是多样化的，有手机，WEB客户端，API访问等。认证的方式包括用户名密码、手机验证码、人脸识别等。微服务化架构，需要考虑分布式的认证鉴权机制，保证分布式认证的安全性和高效性。

1.1 系统内部的认证鉴权

很多应用都有自己的用户和权限管理系统，用户注册后，就拥有了访问应用的权限。系统内部的认证机制已经比较成熟，但是需要考虑的场景仍然非常多样。

从登陆方式看，有如下一些场景：

• 使用用户名密码登录。用户名可以是手机号、邮箱、工号等，同时需要增加验证码功能，以防止暴力破解。

• 使用多重因子认证。除了用户名密码，很多系统还需要提供双重因子认证，比如手机验证码、实名认证（人脸识别），数字证书（U盾），动态口令（E-Token，Authentication APP、等）。

• 人机接口和机机接口需要设计不一样的认证方案。前面的认证方式一般适用于人机接口，机机接口一般会基于Token或者共享秘钥、密钥对等方式完成认证。区分了人机接口和机机接口，还需要对不同的接口做好访问控制和网络隔离。

在微服务架构下，还需要考虑认证的性能。传统的会话管理模式需要共享会话状态实现认证，这个对于认证服务的性能是非常大的考验，容易成为整个系统的瓶颈。

1.2 使用第三方的认证能力

很多应用对于用户角色并不关注，仅仅需要识别用户标识。比如允许微信、支付宝、手机用户登录，用户标识就是微信号、支付宝账号和手机号，而系统则不区分的把这些账号当成本系统用户，拥有类似的权限（当然有些应用场景需要给不同登录方式分配不一样的访问权限）。不同的第三方支持的认证方式和流程是不一样的，比如微信、QQ支持OAuth的不同认证模式接入；手机采用验证码的方式确认身份等。

当用户使用第三方账号登录后，如果需要使用用户的身份访问第三方资源，比如获取微信头像，还需要获取第三方的授权。应用不仅要管理用户访问本应用的会话，还需要管理本应用访问第三方应用的会话。

1.3 给第三方提供认证能力

一些大型企业，需要给第三方提供认证能力，比如github、微信、QQ、支付宝等。OAuth和OpenID Connect协议提供了给第三方提供认证能力的一些标准。很多大型企业都实现了部分的标准，也有些并没有实现，而是提供了不同于协议标准的方式。

 

2 Apache ServiceComb-fence 项目蓝图

Apache ServiceComb-fence 项目最早的想法是给 ServiceComb-java-chassis 提供一个类似 spring security 的开发框架，因为 spring security 大部分是基于WEB应用的，对于非WEB应用支持的并不好。在开始实践的时候，发现 spring security 本身依然复杂，不能够很好的解决用户端到端的认证鉴权问题，使用 spring security，用户需要做大量的分析工作，设计自己的认证流程，开发大量的适配代码。Apache ServiceComb-fence 通过结合 OAuth 2 和 OpenID Connect 协议，发现认证流程标准化和框架化，不仅能够提高鉴权服务的开发效率，还能够帮助开发者解决很多容易疏忽的安全问题。

2.1 Apache ServiceComb-fence总体功能规划

Apache ServiceComb-fence 总体思路是结合 OAuth 2 和 OpenID Connect 协议，提供满足用户多样性认证鉴权的需求。重点是保证系统内部的认证鉴权（包括使用第三方的认证能力）。OAuth 2 和 OpenID connect 协议最早是为“给第三方提供认证能力”而设计的，Apache ServiceComb-fence 在方案设计上和能力开放方面，符合协议的标准。协议设计是为生态构建型企业而生，Apache ServiceComb-fence 则是将这些能力更好的应用到生态参与型企业，帮助参与生态，也为未来构建生态。

上图是 Apache ServiceComb-fence 的场景规划。应用场景方面，支持系统内部认证鉴权，对接第三方鉴权系统和给第三方提供认证鉴权服务。对接第三方和给第三方提供认证鉴权服务，都需要实现不同的认证模式，OAuth2 定义了4个认证模式。微服务架构下，需要考虑安全性和性能的权衡，不同的架构模式不仅能够解决性能和安全问题，还能够支持不同的接入场景和访问控制策略，比如人机接口和机机接口需要采用不一样的架构模式。

2.2 交付件

Apache ServiceComb-fence 提供了API接口，包括适配 authentication server， resource server 和 edge server 的接口，方面使用 ServiceComb-java-chassis 构建用户多样化的认证鉴权系统。详细可以参考项目官网的开发指南。这些接口的设计和实现，也可以作为认证鉴权的实现参考，开发者可以从这里的实现方案中寻到适用于其他框架的实现方案，比如利用 spring security 为 spring cloud 应用实现类似的功能。

Apache ServiceComb-fence 规划了一个 authentication server 实现，开发者可以独立部署和运行这个服务，并将这个服务应用于自己的业务系统，比如采用 spring boot 或者其他语言开发的应用系统。这样用户就不需要自己实现相关的认证鉴权子系统了，能够快速构建认证鉴权能力。通过这种方式，Apache ServiceComb-fence 项目就可以面向其他语言、框架提供认证鉴权服务，丰富其应用场景。

 

3 Apache ServiceComb-fence项目当前进展和社区互动

当前 Apache ServiceComb-fence 已经实现了规划的两大场景，即系统内部认证和使用第三方认证。系统内部认证支持用户名密码认证、Refresh Token 认证。第三方认证实现了总体的代码框架，并通过对接github给出了代码示例。

还实现了三种架构模式。支持 ID Token 和 Session Token 以及混合两种 Token 的接入方式。通过微服务的3个角色：authentication server、resource server、edge service，提供了项目示例和自动化测试。这些项目示例和自动化测试可以作为应用场景的参考。使用提供的演示页面和运行测试用例，可以参考官网的README文件。

3.1 找到项目对于开发者的价值

开发者在贡献开源项目的时候，首先需要找到项目给开发者的价值，这样才能够促进项目的长期持续发展。很多项目由于不盈利，生命周期很短，这不仅没有因为开源代码给其他开发者提供应有的价值，而且可能由于项目的非持续性，给其他使用者带来巨大成本，比如来自安全方面的威胁。开发者可以从几个方面评估参与项目贡献的价值。

• 某个商业项目需要用到开源项目的功能。参与项目贡献，不仅可以帮助开发者完成自己的商业项目开发，还可以从开源项目的参与者里面学习到本领域的知识，将开源项目在自己的商业项目中应用的更好。对于 Apache ServiceComb-fence 安全鉴权项目，则意味着参与者能够理解更多安全威胁和应对措施，减少开发者独立实现探索的成本。更多的使用者可以帮助开源项目发现问题，快速成熟，这种模式是开源项目得以持续发展最重要的因素之一。

• 将 Apache ServiceComb-fence 项目商业化，提供商业版本。商业版本一般可以通过定制功能，增加额外的用户需要的能力，比如提供 SSO 功能、人脸识别功能吸引用户。商业版本除了产品外，还有技术服务，帮助用户提供安全能力方面的咨询和建议。参与开源项目的开发者的咨询建议，对于用户具备很大的价值。Apache ServiceComb-fence 项目则可以促进用户更好的使用 ServiceComb 构筑完整的应用能力。开源项目还可以帮助开发者自助学习，减少了商业版本在用户方面的支撑量。

• 将 Apache ServiceComb-fence 项目应用于其他的开源项目。这种方式也是非常常见的方式。ServiceComb 项目和 SkyWalking、ShardingSphere 都存在合作关系，共同打造面向各种应用场景下用户需要的工具链。

• 个人爱好者或者学生。个人爱好者根据当前正在学习的内容，通过参与项目，能够更好的理解课本上的知识，积累项目开发、协作经验，结识领域内的朋友，能够为以后更好的寻找工作机会提供帮助。

3.2 为项目贡献代码

Apache ServiceComb-fence 项目当前处于初期，有很多功能待完善。下面列举一些识别到的功能：

• 提供常用的认证鉴权方面的库或者示例。比如验证码、手机认证码等。

• 用户管理和权限管理。目前的用户管理只提供了spring security的UserDetailService 的简单数据库实现，实际用户的用户管理需要提供更多的支持。包括不同的用户类型、不同的登录方式以及针对不同用户的不一样的控制策略。

• 蓝图里面规划的对于认证模式的支持。需要提供作为提供者和使用者两种情况下认证模式的支持。作为提供者，目前使用了密码模式；作为使用者，目前提供了 github 的 authentication code 模式。

• OpenID Connect 认证。实现符合标准的 Authentication Server 实现，获取标准认证。

• 性能方面的考虑：提供性能 benchmark，减少鉴权逻辑多于服务访问性能的影响。

• 安全方面的考虑：识别安全隐患，提供保障。

开发者可以通过 JIRA、邮件列表、提交 PR 等方式参与项目。详细说明参考项目主页的说明：

https://github.com/apache/Servicecomb-fence