背景
当前IDaaS EIAM和内部业务方沟通交流的时候，经常遇到的两个问题是：
- IDaaS EIAM怎么支持的多租户场景，怎么做租户切换？
- 有不有接口，提供一个用户的账号ID（手机号、邮箱等），返回可以登录的租户列表？
这个时候，我们的回答都是不能做租户切换，没有这样的接口，因为IDaaS EIAM是纯粹的B2E模型，以企业的视角来做账号的生命周期管理，跨租户之间不存在数据共享。这个回答比较空洞和抽象，在下文中我以常见的几个SaaS应用的账号模型，来尝试说明下不同SaaS应用的身份模型设计。
相关术语
| 术语 | 解释 |
|---|---|
| SaaS | Software as a Service，软件即服务，是一种基于订阅模式通过互联网提供软件应用的模式。 |
| IAM | Identity and Access Management，是一种管理用户身份和访问权限的技术。 |
| IdP | Identity Provider，身份提供方。 |
| SSO | Single Sign On，单点登录，用一个账号就可以登录多个应用。 |
| SCIM | System for Cross-domain Identity Management。SCIM的中文翻译是“跨域身份管理系统”，它是一种开放标准协议，简化了云应用和服务中用户身份和访问控制的管理。 |
常见SaaS应用账号模型
标准钉钉
如图所示，在标准钉钉中，一个账号首先是钉钉的用户，然后这个账号可以加入到多个钉钉企业中，关联到多个在职员工身份，这个时候用户和企业属于同一级的角色。
用户登录时，通过账密（手机验证码等）完成登录后，会默认跳转到一个主企业，然后用户可以在钉钉App的左上角选择其它企业进行切换，这个时候企业就是钉钉的租户概念。也就是这个场景中，钉钉默认提供了一个账号ID关联的企业列表接口，钉钉App基于这个接口来实现左上角切换企业的能力。
这个模型存在什么问题呢？员工账号关联的数据资产所有权不清晰。因为账号首先是钉钉的用户，随后才是企业的在职员工，员工离职以后，仅仅删除的是企业和员工的在职关系，所以这个时候员工离职以后也可以查看聊天记录，存在信息泄露的风险。其它缺点如企业不能限制员工的登录策略（密码有效期限，密码复杂度策略等）等等，均是由于员工账号资产不全部归属于企业，导致离职时候的数据分割不完整。
专属钉钉
鉴于标准钉钉存在的问题，钉钉从而推出了专属钉钉方案：区别于标准钉钉中的账号首先是钉钉的用户，然后才是企业的在职员工，专属钉钉中的钉钉账号完全归属于企业，是因为员工当前在职于这个企业，所以才能登录这个钉钉账号，员工离职后，账号就会被删除掉，这个就是纯粹的B2E模型。
专属钉钉的员工账号的来源于管理员手动在后台添加，或者通过API同步到钉钉中，员工账号资产完全归属于企业，企业管理员可以在后台进行重置员工登录密码和修改关联的手机号码等操作。员工登录时，也可以指定对应的SSO配置，要求员工登录走企业自己的IAM，使用企业的域账号 + 密码来完成登录。其员工的登录界面如下图所示，必须先输入企业组织代码（租户识别），才能识别当前员工的登录方式：
在专属钉钉模型中，员工账号是不存在切换租户的说法，必须先找到租户，才能找到这个员工账号（当前专属钉钉的账号也可以加入到其它企业，实际上也可以做切换，但是专属钉钉的账号仍然归属专属企业，登录时必须先输入组织代码，然后通过专属企业的认证方式来完成登录，相当于专属钉钉和标准钉钉做了功能互通）。
阿里云RAM（主子账号）
与专属钉钉类似，阿里云RAM也是一个B2E模型，企业管理员可以注册一个阿里云主账号，然后为每个企业员工手动创建一个RAM子账号，员工可以通过专属登录页：https://signin.aliyun.com/xxx0476.onaliyun.com/login.htm 来完成登录认证，这个时候租户的识别是以用户名的域名（xxx0476.onaliyun.com）来进行：
在这个模型中，RAM子账号所有权完全归属于企业，对应账号的生命周期管理由企业管理员来操作，企业还可以对员工的登录策略做个性化定义以及配置企业的IdP SSO，以此来满足企业的安全管控诉求：
在这个基础上，RAM还为子账号增加了钉钉扫码登录的认证方式，同一个钉钉账号可以绑定多个RAM子账号，即钉钉扫码后可以选择要登录的RAM子账号，并且多个RAM子账号可以归属到不同的主账号：
这个场景中，B2E的顶层模型并未打破，只是每个RAM子账号可以绑定一个钉钉账号，而一个钉钉账号可以被多个RAM子账号绑定，并且RAM支持根据钉钉账号反查绑定的RAM子账号。
IDaaS EIAM
IDaaS EIAM也是一个B2E模型，不过不同于专属钉钉和RAM，IDaaS EIAM作为阿里云的云产品，不需要关心管理员（主账号）账号的初始化，对应的工作已经在RAM中完成。所有的RAM子账号都可以是IDaaS EIAM的管理员，只要具备EIAM Full Access的权限就可以代为操作归属于RAM主账号的IDaaS EIAM资源。
IDaaS EIAM管理员可以在阿里云控制台手动创建企业员工账号，也可以配置IdP后，从IdP中同步员工账号到EIAM中，此时员工账号的生命周期由管理员在阿里云控制台或者IdP中维护。同理，管理员也可以个性化配置员工的登录策略，以符合企业的安全管控诉求。IDaaS EIAM的租户识别则是直接以域名作为租户的标识信息，后续会在此基础上可以提供自定义域名、自定义登录页的企业个性化配置能力，帮助企业更好完成员工统一管理。
企业SaaS应用的账号模型可以怎么做
企业SaaS应用从部署形态来看，可以分成两种服务模式，一种是部署在企业自己的计算资源中，典型的有JumpServer，可以称为企业自运维应用；一种是在线的SaaS应用，在线服务，开箱即用的模型，如各个云厂商（阿里云也是一个SaaS应用，只不过这个SaaS应用又可以创建出来IaaS资源）、Salesforce。
企业自运维应用一个典型特点是，不存在多租模型设计，但是从账号模型上来讲，也是一个B2E模型，其中管理员身份（主账号）的初始化工作可以借由邮箱或者线下渠道来完成，这种应用提供的能力专注于员工账号（子账号）的生命周期管理，一般会提供简单的账密登录和IdP SSO登录选项。这种模式的应用不属于我们今天的讨论范围。
前文提到的4种典型SaaS应用都属于在线SaaS应用，可以看到的一个特点是，这些SaaS应用都会存在两个实体角色：管理员（主账号）和员工账号（子账号）。需要着重说明的是，管理员（主账号）可以非常明确地认为是SaaS应用的个人客户，只有管理员先成为SaaS应用的个人客户，然后才能基于这个身份去创建归属于管理员所属企业的逻辑租户，而员工账号（子账号）是在企业租户下的一个子资源或者特殊实体，而这个特殊实体会和企业下的真实员工一一对应。
总结来看，如果我们今天创业要构建一个SaaS应用，我们会面临如下几个问题抉择：
- 企业的管理员（主账号）身份怎么初始化？
- 员工账号（子账号）的资产所有权归属于谁，是员工，还是企业？
- 员工账号（子账号）的数据从哪来？或者说，通过什么样的方式快速导入企业的员工账号到应用中？
Q1：企业的管理员（主账号）身份怎么初始化？
在这个问题下，我们可以简化理解成一个To C应用的构建问题，可以通过微信、钉钉、支付宝等社交方式来完成管理员身份的初始化。
Q2：员工账号（子账号）的资产所有权归属于谁，是员工，还是企业？
除了标准钉钉外，本文中其它的三个应用都是以企业视角来看待员工账号，这个账号资产完全归属于企业，因此企业可以个性化定义自己需要的安全管控策略。而在标准钉钉中，员工账号同时依托于个人钉钉账号和企业在职身份，当员工离职后，会存在数据资产分割不清晰的问题。
从个人视角来看，所有的企业SaaS应用都应该从企业视角来看待员工账号，也就是员工账号的资产所有权一定是归属到企业，这样子才能符合企业的安全管控策略。
Q3：员工账号（子账号）的数据从哪来？
除了个别应用外，如HR应用，其它的应用都会面临的一个问题是，企业维护员工人事数据只会在一个地方（HR应用）中维护，我们不能，也不应该让企业IT管理员在一个新员工入职后去多个地方录入该员工信息，即企业员工信息应该一处修改，处处生效。因此作为SaaS应用提供方，我们需要从企业已有的IdP中同步员工身份数据到应用中，此时可选的方式有如下几种：
- 针对已知的权威身份数据源，我们可以主动去适配，如钉钉、AD/LDAP和IDaaS EIAM，通过调用对应身份源的接口来获取员工身份数据；
- 针对未知场景，可以在企业IdP SSO时做懒加载，或者实现SCIM协议，以SCIM Server身份来接受企业IdP的SCIM账户数据同步；
总结
本文从日常业务交流中遇到的两个问题（租户切换和查询用户归属的租户列表）为出发点，针对常见的SaaS应用账号模型进行了一个分析，尝试解答清楚为什么IDaaS EIAM不支持员工账号的租户切换和查询员工账号的归属的租户列表。在此基础上，从个人视角针对企业SaaS应用的账号模型设计做了一个分析，希望能够对大家创建SaaS应用有一个帮助。
