一种基于身份认证体系的多租户管理系统及方法

技术领域

本发明涉及计算机网络领域，特别是指一种基于身份认证体系的多租户管理系统及方法。

背景技术

多租户技术(或称多重租赁技术，简称SaaS)，是一种软件架构技术，是实现如何在多用户环境下(此处的多用户一般是指面向企业用户)共用相同的系统或程序组件，并且可确保各用户间数据的隔离性。在当下云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍可以保障客户的数据隔离。

用户管理是每个产品必备的管理后台，最基础的用户管理只要有账号增删这两个功能就足够，稍微复杂一点，会涉及到用户管理权限的逻辑问题，以及对不同场景下会遇到不同用户管理体系。

针对传统IAM(身份识别与访问管理，简称4A)用户体系下多租户管理方式，目前都是通过后台创建单个租户进行管理维护，并且管理细度不够清晰，只是对租户下用户信息进行管理，各个租户品牌化需求较不相同，租户下用户登录身份源不同，以及企业风格不同，并未有统一标准化能力。

跨租户下用户共享身份也是较为薄弱的地方，一个自然人在不同租户下有自己的身份信息，分别对一个用户两个身份，一个用户多个账号的管理，对平台设计者较为臃肿，对用户自身也是比较繁琐。

现有的多租户数据处理方法中，由于数据库隔离导致多租户间的服务提供方信息难以统一管理，其租户各自拥有一个独立的空间，且无法满足租户之间想实现部分数据共享的需求，应用程序的开发和可扩展性成本较高，每个SaaS公司都要从零开始搭建这些基础设施，前期需要投入很大的成本，竞争激烈，利润后置，研发运维成本投入高，数据利用率较低，用户体验较差。

发明内容

本发明提出一种基于身份认证体系的多租户管理系统及方法，解决了现有技术中上述的问题。

本发明的技术方案是这样实现的：

一种基于身份认证体系的多租户管理方法，包括：

步骤S1、获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；业务场景包括登录注册场景、应用场景、认证场景、权限管理场景、安全审计管理场景；

步骤S2、基于业务数据及其对应的业务场景构建身份认证SaaS数据库，以共享数据库、共享数据架构的方式进行数据存储；

步骤S3、一个自然人为一个用户，针对一个用户设置唯一标识符UID，分别对应其在不同应用下的用户身份Use_ID，不同应用下挂不同租户，并分别为用户对应其不同租户下的用户身份Tenant_ID，一个自然人作为一个用户通过唯一标识符UID进行数据整合；

步骤S4、响应于租户发起的数据获取请求，从多租户SaaS数据库中获取相应的目标数据，并将目标数据发送至租户。

进一步的，以共享数据库、共享数据架构的方式进行数据存储，是指租户共享同一个数据库Database和同一个租户信息表Tenant，但在表中增加多租户Tenant_ID的数据字段；

进一步的，针对目标数据的访问控制方式包括基于角色的访问控制和基于属性的访问控制；

进一步的，基于角色的访问控制指的是通过用户的角色(Role)授权其相关权限；

进一步的，基于属性的访问控制是基于对象、资源、操作和环境信息共同动态计算来决定一个操作是否被允许。

一种基于身份认证体系的多租户管理系统，支持执行以上基于身份认证体系的多租户管理方法。

本发明的有益效果为：本发明提供一种在SaaS多租户用户体系下基于身份认证的管理系统和方法，能够实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，将传统IAM能力在多租户场景下进行扩展复用，为身份认证SaaS租户赋能，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一种基于身份认证体系的多租户管理方法一个实施例的流程图；

图2为本发明一种基于身份认证体系的多租户管理方法一个实施例的基于角色访问控制的原理示意图；

图3为本发明一种基于身份认证体系的多租户管理方法一个实施例中Gitlab的权限系统的示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，一种基于身份认证体系的多租户管理方法，包括：

步骤S1、获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；业务场景包括登录注册场景、应用场景、认证场景、权限管理场景和安全审计管理场景；

由于多租户之间存在实现部分数据共享的需求，通过上述设置，从多租户的服务提供方处获取该部分可以进行共享的业务数据，并根据业务数据划分业务场景，有利于后续通过对该部分业务数据进行整合、处理。

业务场景模块具体如下：

登录注册场景：首先平台中集成了多种第三方登录方式——包括短信+验证码、邮箱+验证码、用户名+密码、邮箱+密码、手机号+密码和APP扫码，每个用户可基于自身登录条件进行登录；同时也支持社会化登录方式，包括但不限于微信扫码和支付宝扫码方式；同时还支持企业化登录方式，包括但不限于OIDC、SAML、钉钉、飞书、企业微信、CAS、AD和LADP，用户可通过接口接入企业内部身份源；

每个租户可自行设置各自的登录门户，通过SDK/API把登录能力，集成到自己的系统中去，从而符合公司文化和品牌价值。

应用场景：通过SDK/API集成接入各种SaaS应用，针对不同的应用可分配个多个不同的租户；针对每个应用，可创建公共的资源，包括但不限于数据资源、API资源、菜单资源和按钮资源；这些资源用于服务于不同租户，同时租户继承不同的资源权限。

认证场景：各租户可通过目前已使用身份认证方式进行集成，集成后可自由配置租户下认证方式。可集成的身份提供商包括但不限于微信、支付宝、OIDC、SAML、钉钉、飞书、企业微信、CAS、AD和LADP。

权限管理场景：应用权限的管理主要是租户下不同主体的权限管理，租户下包括四个级别的主体：用户、分组、角色和组织机构。

针对用户，租户可以在用户详情页的应用授权标签页定义该用户当前能够访问的所有应用。

针对分组，租户可以对自定义的特定一组用户进行分配权限。

针对角色，租户可以对某些用户赋予不同角色，并为这些角色赋予不同权限。不直接给用户授权，是为了之后的扩展性考虑。比如存在多个用户拥有相同的权限，在分配权限的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，给不同的用户分配不同的角色，后续只需要修改角色的权限，就能自动修改角色内所有用户的权限。

针对组织机构，租户可以指定当前组织机构下任意部门访问指定应用的权限，该部门下所有主体都具有经授权的权限。

安全审计管理场景：租户可对管理员和普通用户行为进行审计，针对管理员主要体现为记录管理员的操作类型以及对操作的资源类型记录，针对普通用户主要体现为用户的登入登出以及其他操作类型记录，形成管理员操作日志和用户行为日志，并支持数据导出备份。

步骤S2、基于业务数据及其对应的业务场景构建身份认证SaaS数据库，以共享数据库、共享数据架构的方式进行数据存储；

以共享数据库、共享数据架构的方式进行数据存储，是指租户共享同一个数据库Database和同一个租户信息表Tenant，但在表中增加多租户Tenant_ID的数据字段。这是共享程度最高、隔离级别最低的数据存储方式，但是所需费用最低。

步骤S3、一个自然人为一个用户，针对一个用户设置唯一标识符UID，分别对应其在不同应用下的用户身份Use_ID，不同应用下挂不同租户，并分别为用户对应其不同租户下的用户身份Tenant_ID，一个自然人作为一个用户通过唯一标识符UID进行数据整合；用户通过唯一标识UID合并后，登录时通过选择不同账号进入不同应用的不同租户下。

在一个实施例中，用户的唯一标志符UID为手机号，在多租户场景下，每个应用都分配唯一标志符Use_ID，每个用户在每个应用下都生成唯一身份User_ID并与用户的唯一标志符UID相关联；不同的租户下挂在不同的应用下，为每个租户分配唯一标志符Tenant_ID，在每个租户下每个用户也都生成唯一身份Tenant_user_ID与用户的唯一标志符UID相关联，数据集方式如下：

/>

步骤S4、响应于租户发起的数据获取请求，从多租户SaaS数据库中获取相应的目标数据，并将目标数据发送至租户。

针对目标数据的访问，有两种访问控制方式，分别是基于角色的访问控制(Role-basedaccesscontrol，简称RBAC)和基于属性的访问控制(Attribute-BasedAccessControl，简称ABAC)。

如图2所示，基于角色的访问控制(Role-basedaccesscontrol，简称RBAC)，指的是通过用户的角色(Role)授权其相关权限，这实现了更灵活的访问控制，相比直接授予用户权限，要更加简单、高效、可扩展。

当使用RBAC时，通过分析系统用户的实际情况，基于共同的职责和需求，授予他们不同角色。可以授予给用户一个或多个角色，每个角色具有一个或多个权限，这种用户—角色、角色—权限间的关系，让我们可以不用再单独管理单个用户，用户从授予的角色里面继承所需的权限。

如图3所示，以一个简单的场景(Gitlab的权限系统)为例，用户系统中有管理员角色Administrator、维护者角色Maintainer和操作者角色Operator三种角色，这三种角色分别具备不同的权限，比如只有管理员角色Administrator具备创建代码仓库、删除代码仓库的权限，其他的角色都不具备。

授予某个用户「Administrator」这个角色，他就具备了「创建代码仓库」和「删除代码仓库」这两个权限。

不直接给用户授权策略，是为了之后的扩展性考虑。比如存在多个用户拥有相同的权限，在分配的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，给不同的用户分配不同的角色，后续只需要修改角色的权限，就能自动修改角色内所有用户的权限。

基于属性的访问控制(Attribute-BasedAccessControl，简称ABAC)是一种非常灵活的授权模型，不同于RBAC，ABAC则是通过各种属性来动态判断一个操作是否可以被允许。

在ABAC中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。

对象是当前请求访问资源的用户，用户的属性包括但不限于ID、个人资源、角色、部门和组织成员身份；资源是当前访问用户要访问的资产或对象，包括但不限于文件、数据、服务器和API，资源属性包括但不限于文件的创建日期、文件所有者、文件名、类型和数据敏感性；操作是用户试图对资源进行的操作，常见的操作包括“读取”、“写入”、“编辑”、“复制”和“删除”；环境是每个访问请求的上下文，环境属性包括但不限于访问尝试的时间和位置、对象的设备、通信协议和加密强度。

一种基于身份认证体系的多租户管理系统，支持执行以上基于身份认证体系的多租户管理方法。

本发明的有益效果为：本发明提供一种在SaaS多租户用户体系下基于身份认证的管理系统和方法，能够实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，将传统IAM能力在多租户场景下进行扩展复用，为身份认证SaaS租户赋能，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。