设计思路

 

序言

我是从用户中台的业务点出发，结合统一身份认证管理系统（4A或者IAM）来设计用户中台。我得益于《平台级SAAS架构的基础：统一身份管理系统》这篇文章，在这个文章的基础上结合公司现有和将有的业务进行了修订。

一些概念：

4A管理：集中账号管理（Account）、集中认证管理（Authentication）、集中授权管理（Authorization）和集中审计管理（Audit）

IAM：Identity and Access Management，即身份识别与访问管理

出发点

我主要是从用户中台的用处出发来构思整个业务架构。用户中台，位于业务中台和数据中台之间，可以看做是一类特殊的业务中台。

用户中台主要是干什么的？

对于2C：

• 我需要登录么
• 我怎么登录，手机密码、手机短信验证码、第三方登录（微信、QQ、微博等）
• 我怎么注册，手机号注册、邮箱注册
• 我怎么能够注销账号
• 我是否需要实名，如何实名

对于2B而言，很多用户账号是由2B业务系统的管理员分配的（大多数CRM、ERP、OA），现在也支持通过管理员发送邀请（既有2B又有2C业务，比如钉钉、teambition、石墨等）

• 组织如何注册
• 组织如何实名
• 组织如何登录（组织管理员如何登录）
• 员工怎么登录，手机密码、手机短信验证码、第三方登录（微信、QQ、微博等）、账号名称/ID
• 怎么创建、删除、禁用员工账号
• 管理员怎么邀请员工加入到这个虚拟“组织”
• 组织如何分配员工权限（控制访问）

综上，用户中台要满足管理账号（组织和个人）、权限的基本需求。

咱们把时间线拨回到用户中台出现之前。之前企业的业务系统是由各个部门负责，比如大家熟知的OA系统、财务系统、CRM和ERP等系统，这些系统有不少是由某个部门提出然后公司推广使用的。这时候就会发现，这些系统的数据是不通用的，每个系统都需要把员工和组织录入一遍。一旦员工变动，那么所有业务系统都需要全部更新一遍。

为了解决这个问题，有的系统就提供了接口或者数据导入的功能，允许将某个系统的相关信息同步到其它系统。但这样也有问题，数据是同步了，但是登录没有同步，员工上班后需要依次登录系统，不能一次登录所有关联系统。于是就诞生了单点登录和后面的4A统一身份认证管理平台，前者解决了一次登录所有系统（后续还有单点退出），后者解决了用户账号、认证、授权、审计4个问题。

用户中台继承了4A管理平台的核心功能中的账号、授权，认证及鉴权一般放到了API网关中（微服务架构）。为此我基于统一身份管理来设计公司的用户中台。

统一身份管理功能

统一身份管理必须具备管理平台下所有系统的账户管理、身份认证、用户授权、权限控制等，并且为其它系统提供账户密码管理、个人/组织基本资料管理、角色权限等功能。

从平台角度上来看，平台的用户分为两类，一类是个人用户，一类是组织用户（还有一类是系统用户，隐藏的）。个人用户非常常见，全部的C端应用和部分B端应用都是基于个人用户体系的。

关于组织用户（账户）其实在一些平台中也是非常常见的，比如微信有个人公众号和企业公众号；银行有公司账户和个人账户，支付宝和微信也有类似的账户；苹果的开发者账户有个人、企业之分。需要注意，大部分组织账户都可以绑定到某个个人账户。

总体上，这个同意身份管理应该满足以下需求

编号	需求	描述
1	统一登录	SSO
	统一注册	统一的用户注册页面
	实名认证
	账户注销

从功能角度来看，可以分为以下模块，详见脑图

• 账户
• 认证
• 组织管理
• 权限管理
• 授权管理
• 鉴权中心
• 系统管理

 

账户体系和权限管理

前面提及，统一身份管理中用到了2类账户体系，个人账户和组织账户。在涉及多租户概念的平台中，个人账户和组织账户都是不可或缺。一般来说，个人账户可以从属于某个组织。

 

基本原则

账户体系和权限管理遵循以下原则

• 个人账户统一原则：个人账户一次注册，全平台通用，类似于全网通行证和 SSO。
• 业务权限独立原则：每个子系统的权限体系是独立的，但是由用户中台统一管理维护。『个人账户统一原则』明确了账户体系是统一的，但是对于每个子系统而言，每个账户所能使用的功能和服务，所能查看的数据权限是独立维护的，比如 XXX 公司（组织）-研发T3组（用户组）-张三（用户）-研发人员（角色），在 CRM 系统中，拥有的资源权限（详见下文），与其在 OA 系统中的所拥有的资源权限肯定是不一致的。
• 组织实体隔离原则：不同的组织实体之间，是相互隔离，独立管理的。每个组织实体可以自行组织自己的组织体系、账户体系和权限体系。不同的组织实体资源权限也是隔离的。
• 从属关系隔离原则：个体账户与组织实体的从属关系是基于单独的业务系统存在的，『个人账户统一原则』明确的仅是个人账户的全网统一，但组织实体、从属关系并没有统一，并且是隔离的。比如在 CRM 系统中，张三（用户）从属于 XXXX 公司（组织），但在 OA 系统中，张三（用户）默认是不从属于任何组织的，从属关系受到具体业务系统的影响。事实上，这个原则是非强制的，具体取决于各自的业务逻辑和业务场景。如果要简化从属关系的管理，那么可以不遵循此原则，即个体账户与组织实体的从属关系是全平台统一的，与业务系统无关，但这会为降低平台的灵活性和扩展性。灵活性和复杂度之间通常要做一个取舍。

 

权限原则

用户中台的权限体系是基于RBAC概念，这个RBAC是基于资源的RBAC而非基于角色的RBAC

• 各业务系统的权限是相互独立的，没有依赖关系
• 各组织的数据也是相互独立，相互隔离
• 业务系统的权限遵从于基于资源的RBAC
• 数据权限受限于数据规则
• 权限并集：与 RBAC2 的静态职责分离-角色互斥原则相反，平台采用多角色权限取并集的设计。即在某个业务系统中，用户可以拥有多个角色。此时用户在该业务系统的权限等于各角色权限的并集

为满足以上几点，权限体系中必须有系统标识；数据资源权限中不仅有组织标识，还必须要有部门标识和创建者标识，部门标识和创建者主要是便于区分消费者和生产者。

ps：目前并未设计用户组和角色组概念

扩展

在序言中提及到的《平台级SAAS架构的基础-统一身份管理系统》文章中，作者用的是OS-RBAC权限体系，其中O是Orgnization组织，S是Systerm系统。笔者解释这个体系说明权限受组织和系统双重约束。

这一点我是赞同的，权限是依赖于系统，数据依赖于组织。这个在多租户体系中尤为明显，A公司的管理员不能看到B公司的数据，因为A和B是两个不同的组织；同样，A公司的组织架构、权限体系可以和B公司的完全不一样。

考虑公司平台的业务完全没有达到SAAS级别，且业务主要集中在自用和第三方开发者接入使用。为了降低复杂度，我降低了组织对权限的影响。简而言之，在某个业务系统中，所有管理员的功能权限是一样的（数据权限除外，因其受到组织影响），因角色受系统影响不受组织影响。

用户类型

下图来源于《平台级SAAS架构的基础-统一身份管理系统》，这个里面概况的用户类型非常详细。我将组织用户和行业用户都放在了组织用户概念中，与前文的组织账户对应。。

 

 

 

服务分解

微服务架构下的服务分解有两种方式，一种是基于业务能力的分解方式，一种是基于DDD领域驱动子域分解。由于我还在学习DDD领域驱动，故先基于业务能力来分解服务。

以下是具体的服务及业务能力：

1、账号类服务

• 账号管理服务
• 注册服务
• 注销服务

 

2、权限类服务

• 角色服务：
• 权限服务：

 

3、组织类服务

• 组织管理服务
• 组织机构管理服务

 

4、授权类服务

• 授权服务：绑定/解绑角色权限，绑定/解绑用户角色，绑定/解绑用户和系统，绑定用户和组织机构

 

5、鉴权类服务

• 登录鉴权服务：登录方式配置、登录风控和登录鉴权3个业务能力
• 其它访问鉴权：负责外部应用访问内部服务的鉴权

 

6、认证类服务

• 认证服务：包含个人实名认证、组织实名认证和人证资质审核3个业务能力

 

7、系统类服务

• 系统管理服务：负责系统的增删改查

 

 

 

 

 

 

参考链接

1、平台级SAAS架构的基础：统一身份管理系统