基于业务中台的多租户权限管理设计方案

27 评论 52130 浏览 255 收藏 8 分钟

文章是基于业务中台多租户权限管理设计的整体方案,笔者梳理了后台系统权限管理设计的一般方法、需要解决的问题以及总结了具体的设计方案。

一、后台系统中权限管理设计的一般方法

在设计后台系统(如:CRM、EPR、EHR、电商管理后台等)时,权限管理是必不可少的功能,绝大部分的后台系统都是处理企业业务流程的,会涉及到多个部门的协同合作,必然需要对每个能够使用系统的用户进行权限管理。

在一般的单体应用的后台中权限管理的大体模式如下:

整体的业务逻辑如下:

  1. 系统中的菜单、页面、按钮、字段以及运行时产生的数据都需要注册成为系统资源;
  2. 系统资源打包组合成为角色;
  3. 角色可以关联用户,也就完成了资源授权给用户的处理
  4. 角色可以关联用户组,而用户组是多个用户组合而成的一个集合,用户能够继承用户组关联的角色

而在系统运行时,任何一个用户在使用系统资源时,都需要进行授权校验,也就是看这个用户关联的所有的角色囊括的资源是否包涵当前要访问的资源,如此就完成了用户权限管理的控制。

你没有看错,所有的单体应用的权限管理的实现逻辑都是如此。

但在基于业务中台的基础之上去做权限管理的设计我们需要额外引入更多的概念(租户、应用实例等)以完成业务逻辑。

二、基于业务中台的多租户权限设计需要解决的问题

所有中台建设的目的都是为了业务快速且低成本创新,绝大部分的企业基于中台都会开发大量的业务应用,一般基于业务中台的架构如下图:

从图中可以看到,在中台之上有针对各个业务开展的各种应用,而笔者所在的企业是一家中台标准产品的厂商(即把中台作为基础设施的SaaS厂商),更是加入了多租户的机制以满足不同客户对应个性化的需求。

在基于中台的多租户、多应用的场景下,我们做权限管理的设计面临如下主要问题:

  1. 在出厂时需要提供特殊的初始化权限管理流程;
  2. 对于购买SaaS产品的客户而言,权限需要集中进行管理,以减少运营人员的工作内容;
  3. 对于不同的角色/场景有不同的权限管理的需求。

三、具体的设计方案阐述

在解决以上问题之前我首先介绍下我们公司的整体产品架构:

业务中台是我们所有应用的基础设施,我们能够通过MPC 配置各个应用所需要的业务能力,把业务能力组合起来就能形成一个应用,如此我们实现了业务中台的能力复用以及快速支撑业务创新。

在这个业务模式中,应用均是通过配置在进行一定的前端页面开发形成,我们可以为每个租户生产其所需要的应用实例,租户下的数据是隔离的。

在客户购买我们整个标准产品后(包括业务中台、MPC、BOC以及预置应用),首先我们在MPC中预置了一个root账户,通过该账户我能够创建租户,并为租户实例化应用,在实例化应用的同时,为该租户生成在该应用实例下的租户管理员。

租户管理员能够进入BOC进行全局的权限管理,例如:他能在该租户下创建用户,并设置该用户能够登录的应用;他能为租户下的任一应用实例创建角色,并把该角色分配租户下的用户。

租户管理员管理权限的模式如下:

整体业务逻辑:

  1. 系统初始化时,需要生成root账号,该账号由系统预置所有资源权限
  2. root账号能够创建租户,并为租户实例化应用
  3. 实例化应用的时候需要为租户生成租户管理员并赋予租户管理员该应用实例的管理员权限(管理员角色为应用预置)

以上是解决出厂初始化时的特殊的权限管理处理逻辑。

租户管理员能够在全局管理(BOC)中管理租户下的用户信息,并能够为用户关联应用及应用中的角色;

原型示意图

租户管理员能够在全局管理中管理每一个应用实例中角色;

具有应用实例权限的用户能够进入应用,并创建该应用实例下的用户、角色。

四、总结

以上就是我在基于业务中台多租户下权限管理设计的整体方案,租户是在SaaS模式下隔离数据使用,在数据层面有自己的独立空间;

应用实例指的是租户数据空间中运行的应用;用户是使用系统的直接对象,其能够使用资源是由其关联的角色决定;资源指的是系统中的菜单、页面、按钮、字段以及运行时产生的数据。

理清这些概念后即使是再复杂的系统我们进行权限管理设计也是不在话下。

对应上内容如有异议,欢迎大家随时与我探讨。

 

本文由 @keeliu 原创发布于人人都是产品经理 ,未经许可,禁止转载。

题图来自 unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 可以加个V 沟通吗

    来自北京 回复
  2. 有没有超级管理员管理所有租户说法?例如这个超级管理员能看和操作所有租户数据且一租户一独立数据库。

    来自广东 回复
  3. 有个问题咨询下:多租户模式下,您文章里的所列的应用,可能会涉及到C端用户,商家,平台运营人员(管理员),或者还有供应链端(工厂端),那这些用户都当作租户来定义么?存储在一起 还是会分开?

    来自山东 回复
    1. 以一个企业为单位进行租户定义

      回复
  4. 非常感谢 有收获

    来自福建 回复
  5. root属于哪个租户呢?

    来自广东 回复
    1. root属于管理员,和admin是一个意思,Linux系统中常用的,不属于租户

      来自陕西 回复
  6. 用户和租户有啥区别呢?

    来自浙江 回复
  7. 和我们现在做的多系统集成平台的后台管理思路差不多,有空我也写一篇交流一下

    来自陕西 回复
    1. 写了吗

      来自福建 回复
  8. 希望能继续展开讲讲. 写的非常好哈. 尤其中台控制管理台里的模块再进一步讲就好了

    来自广东 回复
  9. 再说句,作者把事儿说复杂了

    来自浙江 回复
    1. 到底怎么样的业务中台-用户中心才是合理的呢?

      来自广东 回复
  10. 一个用户有多个角色可以获取多种系统资源,一点儿都不难;难在怎么针对用户的不同场景来隔离角色,避免资源一股脑儿甩给他,让他自己来挑选(谁让他有这么多角色呢)。所以,角色/权限定义没毛病的前提下,,,问题的核心在于如何识别用户使用系统的场景,最简单的办法当然是分系统或者分端咯,用物理隔离的方法。复杂一点就要深入业务流程中,看看上他进来操作的业务目的是啥,一般情况下一种角色代表一种特定的业务目的,如果业务目的可以明确了,那么系统自动帮忙选角色也不难了。

    来自浙江 回复
    1. 看到你的评论很受启发,谢谢`

      来自上海 回复
    2. 到底怎么样的用户中心,才是合理的呢?

      来自广东 回复
  11. 来加我这10年老🐦

    回复
    1. 大部分文章都看到你的留言

      来自广东 回复
  12. 总觉得用户组的概念有点模糊,角色定义了权限范围,然后关联一批用户,形成用户组,此时角色和用户組是一对一的,但是看你的关系图怎么感觉是一组多个角色??

    回复
    1. 同一角色,可以同时属于多用户组,同一用户只能归属一个组。

      来自北京 回复
    2. 能否理解为用户与用户组是多对一,用户和角色多对多,用户组和角色多对多?

      来自广东 回复
    3. 用户组和角色是一对一的,那么使用角色是不是可以代替用户组呢?单独弄一个用户组的核心目的是啥?

      来自四川 回复
    4. 这里用户组应该只是多个用户而已,没什么特别的含义(和多个用户分别对应角色一样)。作者想要强调的应该是权限是角色定义的,然后不管是用户还是用户组都是通过和角色多对多来获得权限的。

      来自北京 回复
  13. 不得不说 真的没看懂

    来自浙江 回复
    1. 这篇文章中用户管理模块是用于 统一用户体系用于多应用的模式种,比一般的单应用系统会复杂点。解决的场景:一个企业内部可能有多个应用(erp\crm\wms等)想用同一套用户体系进行管理。

      来自广东 回复
    2. 我的意思是:你的文档写的没看懂

      来自浙江 回复
    3. 我看懂了

      回复