组织领域模型定义

[Guo-Zhang]

Organization的嵌套关系有两种：

1. 树状，即简单的父子关系。
2. 树+标签，即允许组织形成标签关系，类似于“项目组合”。

每个Organization有自己的租户Tenant隔离资源。

OrganizationUser组织用户。用户在组织内的唯一身份。
同一个用户在相关的不同组织的身份，可以采取的设计方式：

1. 同步信息。优点是架构简单，缺点是需要解决一致性问题。
2. 引用某个组织的身份。优缺点和上面相反。

OrganizationUserGroup组织用户组。比如部门Department、委员会Committee等。

[Guo-Zhang]

组织内部关系

用户关系

OrganizationUserRelation组织用户关系。建模上下级关系等。

简单版本：

• id
• subordinate: 下级
• superior: 上级

足够表达用于项目管理和人力资源领域的“汇报”关系。

复杂版本：

• id
• from
• to
• type: 定义新模型

OrganizationUserRelationType字段为：

• id
• name：建议动词，比如report。report在人力资源和项目管理都要用。
• name_from: superior
• name_to: subordinate
• verbose_name
• verbose_name_from
• verbose_name_to

可以表达更通用的关系，但是可能过度建模。可从上述模型演进。

用户组关系

OrganizationUserGroupRelation组织用户组关系。建模所属关系等。

简单版本：

• child
• parent

复杂版本：类似上面。

通用模型

可能过度设计。

OrganizationEntityRelation组织实体关系。

类似于上述from和to，只不过不再是ForeignKey，而是用UUID来标记User和UserGroup。

技术实现

可考虑使用DAG有向无环图定义，如果我们假设只有上下级关系/父子关系。

使用一般图也可以，如果我们认为组织中的其他关系也要被建模。

[Guo-Zhang]

使用场景

服务端：

1. HR领域创建Department和Committee。
2. IdAM领域被HR领域调用接口创建关联的OrganizationUserGroup。
3. 项目管理领域使用OrganizationUserGroup。

客户端：

1. 调用IdAM服务的OrganizationUserGroup的API。
2. HR领域模型转换成Department和Committee。
3. 项目管理领域使用。

两种方案的主要区别在于Department和Committee模型理解成跨服务的多态模型还是仅仅为关联模型，后者需要自己的UUID。

[Guo-Zhang]

初步决定使用多态模型建模。在微服务系统里更容易使用同一个UUID做跨服务的操作。

Group这里允许用户自己定义Type，具体由定义方决定怎么使用。Department和Committee被当做type被注册，通过序列化类来实现API。前端直接调用IdAM的API或者调用HR的API都可以获得同样的结果。

[Guo-Zhang]

请 @huangrihang 补充我们的讨论到此Issue。

[huangrihang]

Q1：同一个用户在相关的不同组织有不同的身份，是否意味着租户没隔离完全？
A1：租户在IdAM内部和外部的体现是不同的：
在IdAM内部，量潮租户里面存了每一个租户的信息（主要是存储各个租户的超级管理员身份），量潮租户里存的其它租户信息与IdAM内部的其它租户是一一对应的；
在IdAM外部，各个服务里直接分为各个租户。

这个问题是跨组织同步用户信息的问题。
一种是父组织在子组织的身份需要同步，比如我在量潮科技、量潮助研、量潮课堂的身份，这里把助研项目建模成一个子组织；
另一种是组织参与外部组织，比如我们以机构身份参与到某个开源项目，也需要同步，比如我们参与北极星。

[huangrihang]

Q2：跨组织同步用户信息没问题，但是“每个Organization有自己的租户Tenant隔离资源”每个组织直接一个租户？
A2：有两种方向：一种方向是这样，还有一种是嵌套租户，嵌套租户听起来美好，实际上没办法设计隔离方案。Vault使用的是namespace，允许嵌套，也是推荐的多租户方案。嵌套租户我也确实查到了一些资料，这些方案基本上都是租户ID隔离居多，本质上也是把IdAM的事情放到了租户层面处理，所以目前看只能每个组织一个租户这么设计。

[Guo-Zhang]

组织和租户的对应关系

方案1：一个组织对多个租户，对不同部门设置不同的租户权限，向上暴露租户。

方案2（个人推荐）：一个组织对一个租户，组织及其子组织对不同租户有不同权限，从而实现跨租户访问。

方案3：嵌套租户，组织和嵌套对应。

[Guo-Zhang]

在IdAM里，我们假设遵循多租户规范，把单租户看成多租户为1的特殊情况，即把C端系统作为B端系统的特殊情况。

因此量潮IdAM规范依赖量潮多租户规范。