01

向云而生，IAM 到 IDaaS

IAM 是“Identity and Access Management ”的缩写，即“身份识别与访问管理”。IAM 是一套通过全面建立和维护数字身份，并提供有效地、安全地 IT 资源访问的业务流程和管理手段，从而实现组织信息资产统一的身份认证、身份授权和身份数据的集中管理与审计。

通俗地讲：IAM 是让合适的人在恰当的时间通过统一的方式访问授权的信息资产，提供集中式的数字身份管理、认证、授权、审计的平台。

我们为什么还需要 IDaaS？是因为传统的 IAM 有几点不足：

1）运营能力弱，传统 IAM 账号中心的运营能力较弱，难以满足大型组织在业务方面的需求，例如，筛选出六个月内未登录过的用户，并向他们发送营销短信；或找到那些高频使用的用户并交由客户经理转化商机。

2）缺乏伸缩性和扩展性，当企业的用户量不断上升时，用户系统承载的压力也会不断增加，传统的 IAM 主要靠堆积服务器和设置负载均衡来优化，但登录失败的次数总是随着用户量的增长而增长，这对企业和用户来说都是灾难。

3）运维费用高，大多数 IAM 专家难以雇佣并且费用高昂。而且当企业计划将内部员工训练成专家时，他们面临着将训练好的员工流失到咨询公司或竞争对手那边。

4）安全性欠佳，数据资产正在逐渐超越实体资产成为企业最有价值的核心。而针对数据资产的盗窃和攻击也呈不断上升趋势。传统的 IAM 在本地构建，难以保障混合云环境下的企业安全，权限管理颗粒度较粗，访问控制策略单一。

5）难以更新换代，大多数企业的 IAM 系统需要消耗巨大的人力物力去更新换代，而当企业耗尽千辛万苦将系统更新好了之后，市面上又出现了新的技术和系统。

IDaaS 是在 IAM 基础上加上了云计算，相比 IAM 增加很多优势：

• 多种认证与访问控制策略、灵活高效；
• 基于云原生架构、天然适应，海量数据存储；
• 多维度保障数据安全；
• 在 IAM 的基础上实现全面拓展。

02

Authing 就是身份云

云计算有 IaaS、PaaS 和 SaaS 三层。

Authing 的能力是一种可复用的身份基础设施，是以身份作为基础设施的一种来看待我们这个产品。

从云计算角度看 IDaaS，Authing 更多是 PaaS 和 SaaS 之上的一层，面向应用和用户侧。近年来联网的设备爆炸性增长，企业级的数据量也在增长，企业所用到的应用也在增长，我们是在这之上提供了统一的组件，它包含登录、注册、身份鉴权、用户交互这些功能，在 PaaS 和 IaaS 之上 SaaS 层提供了云的统一身份管理解决方案。

软件发展初期，“身份是软件一部分”的方案由于成本和复杂性的限制。如今，我们使用Facebook 的社交账户去登录其他平台。未来我们希望看到通过 Authing 这种统一的身份平台去连接任何组织和任何应用。

「ECUG Meetup 第 2 期」活动中，Authing CTO 尚斯年提到，我们面对客户有不同的交付环境，私有云、混合云、公有云，我们是如何交付我们的产品？在这之上我们提出了“云中立”的概念，我们的产品交付在用户任何云环境上。

比如这个客户只 30 个人，没有必要太复杂架构，在我们平台一个 SQLite 就可以跑起来。如果这个用户是 2000-10000 人的规模，需要一定可靠性、安全性的保障。

未来必须要有个统一的或者中心化的平台来解决所有身份问题，这同样也是我们的愿景。Authing 作为一个通用平台，既能支持云应用、IoT 应用；也能支持设备、私有云平台以及不同的组织；不仅如此，我们还能支持统一的面向私有云、公有云、混合云身份解决方案。

私有化方案这一点上，我们可以使用开源组建进行替换。我们开发者用户或者中小企业说没有必要私有化部署，直接用公有云平台，我们是在公有云之上提供公有云的解决方案和组件，这些东西都是可以替换的，我们做一套适配层 Adapter，可以在任何云平台上部署我们的产品。我们的产品已经部署在腾讯云、阿里云、AWS、Google 和用户的私有云上。

Authing 在公有云上也有一套高可用的架构设计，这也是比较经典的一套，就是多 Region 的概念。

03

面向服务的认证与授权

在微服务架构，尤其云原生倡导微服务时，如何进行服务治理？服务之间是如何完成认证和授权的？有没有统一的方案？

Authing 基于 OpenID 的标准协议实现 M2M 的身份授权解决方案，M2M 是 Machine-to-Machine 的缩写，指的是服务之间的认证与授权。

举个简单的例子，如果你是个外包商，需要将业务 API 提供给业务方，几个外包商给客户开发一个大屏的数据展示，你希望将某些非核心的 API 访问授权给外包商，外包商完成非核心部分应用开发需要授权，过程中不需要用户参与，只需要确定来访者是哪些外包商以及哪些接口。

授权就像左图的服务 A 调用服务 B 和服务 C，B 允许服务 A 调用时，有让服务 A 调用服务 B 的权限，C 没有这样的权限。我们发现这种模式有一个问题，就是对代码有侵入性和耦合性，像服务 B 时、服务 C 有个专门认证模块，去判断服务 A 是否能调用，这些与业务无关的认证模块很有必要，我们可以在中间加一个统一的中间件 Authing，所有的认证控制都是通过 Authing。

04

开发者友好的身份云

我们做身份云平台之中非常关注开发者体验，这也是云原生很重要一个概念。

我们产品迭代有个概念叫「API First」，将所有能力 API 化提供给开发者。我们的目标是开发者完全可以基于我们平台的 API 做一个和我们平台一模一样的产品。用户可以通过不同设备访问我们平台全量的 API。

这是面向开发者最大的价值，在 CNCF2020 开发者现状报告中，现在全球有超过 470 万开发者在使用云原生技术，占全部后端开发者的 36%。开发者已经成为云原生变革最主要的推动力量。

我们在平台中提供全量的 SDK 和 API，后端的像 java、Python、.NET，前端的像 JavaScript，安卓、iOS，还有跨端的 React Native、Flutter。希望 API First 的体系架构是一种设计方法，它以 API 为中心，我们认为 API 开发出来的应用就像乐高积木一样模块化，是可复用可扩展的。面向 API 就是面向开发者，可以更好将身份服务集成在开发者和企业的业务当中。

在 API 之上我们提出了 Hyper Component 的概念。经常我们把 API 交付给客户时，客户说用你的 API 要进行二次开发，还要封装组件。我们将登录框做成组件的形式，只需要几行代码就可以嵌入到我们的应用系统平台之上。考虑到前端有不同的框架，我们也面向不同前端框架提供统一的组件化方案，同时支持 React、Angular 和 Vue，完全可以集成在企业和开发者自己的平台之中。

虽然我们提供了 API、提供了组件，用户的诉求是千变万化的。举几个用户常见的想法：

• 想要获取用户注册来源；
• 想要在系统维护期间，禁止用户访问登录；
• 注册之后，希望自动发送钉钉、企业、飞书信息；
• 希望在白名单的用户才可以访问；
• 希望收到邀请的用户才可以访问。
  …

用户的诉求无穷无尽，有没有一种方式尽可能满足用户的诉求？

我们还创建了「Authing Pipeline」的概念。Authing Pipeline 是一组运行在云端的用户自定义 JavaScript 代码，可以让开发者扩展、自定义 Authing 能力。在认证身份流之中，登录、注册前后都可以插入钩子执行用户定义的函数。所以身份服务是一种统一平台，面向用户不同场景，去适应用户的场景。

还有一个问题是用户担心数据的安全性，尤其是外企的用户经常说你们的数据是不是被政府所监控？我们核心业务数据放在你这不安全？所以我们提供了自定义数据库的功能，用户的数据完全由用户做主，企业或开发者的数据并不存储在 Authing 上，在每次认证时通过调用脚本访问自身平台的数据，这种方式有一定的性能损耗，但是安全性更好，我们提供了这样一个自定义数据库的连接。

我们有两种数据库连接模式。一种是惰性数据迁移模式，每次用户访问自身数据库，完成信息比对之后将数据惰性迁移到平台；还有一种完全使用你自己的数据库，我们平台只完成用户身份认证，不存储任何数据。这种模式是通过脚本，脚本是 JavaScript，可以连接像 MangoDB、MySQL 数据库等等。

上图是完整的技术方案，在用户完成认证的时候，我们进行函数计算，函数计算也是通过后台上传的，像 AWS 或者阿里云、腾讯的云函数计算，用户通过自身云函数计算访问自身数据库完成数据接入。

这个方式也有问题：

• 构建和上传速度慢、用户体验差；
• 有网络通信时间延迟，登录等待时间长；
• 函数冷启动问题，虽然现在各大平台将函数的冷启动基本解决了，面向温启动，几十毫秒之内能够启动，但是对用户来讲也是没必要的损失；
• 和我们云平台耦合性比较重，私有化部署时无法实现快速接入。

我们找到了 Safeify 的 Javascript 沙箱解决方案，相比之前其他沙箱模式这个方案提供更好的资源隔离能力。这种沙箱可以通过进程池管理调度沙箱进程，处理的数据和结果，还有公开给沙箱的方法，针对沙箱进程进行 CPU 和内存配额限制。它的核心是沙箱运行在不同进程，然后完成任务。

05

Authing 快速发展背后的云原生技术

Authing 在 2 年内完成快速发展，去年完成第三轮融资，我们平台有千万级的客户，我们是如何做到这些的呢？

第一点，构建基础设施及代码方案。使用 Terraform 编排。业务上云对 IT 基础设施的管理提出了更苛刻的要求，我们需要：

1）更好的系统效能：及时了解相关领域而规避了风险，确保了合规和 IT 基础设施的安全；

2）更快的速度：在今天，软件交付/更新的速度被认为是成功背后最重要的因素之一，需要保证基础设施的高效迭代；

3）高效的变更管理：在部署到生产环境之前，代码常常被修改和测试。基础设施即代码确保了在不同设备、平台和系统中实现更安全和高效的变更管理；

4）可扩展的基础设施：硬件的虚拟化使得在需要时增加、替换和扩展资源。

面对这个问题，我们使用了 Terraform 这个编排。给客户交付时，如果客户希望部署在阿里云平台，也基于 Terraform 进行快速基础设施搭建，当用户有基础设施和环境变更时，可以快速完成底层基础设施的变更，而且每次变更都是有迹可寻的。

第二，持续交付。云原生系统之中应该关注用户交付能力。并没关注以下两点：

1）概念和操作尽可能简单，每一个成员无论技术水平高低，都可以可以快速理解 CICD 流程并将自己代码发布到不同环境。

2）最小适用，如无必要勿需增实体，用尽可能简单的组件完成代码集成和上线交付。发展之是，我们希望所有的东西尽可能简单，一个组件完成交付，就不会扩大更多组件，保证系统的复杂性。

第三，日志与监控。我们是一个 SaaS 平台，保证 7×24 小时高可用，有任何线上问题要及时暴露出来，这张图展示的是我们基于 Prometheus 的监控与报警解决方案。

点击此处了解更多行业身份管理

「解决方案」以及「最佳实践案例」