Multi-tenant permission configuration method, system, device and medium based on SaaS platform

Abstract

The present invention discloses a multi-tenant permission configuration method, system, device and medium based on a SaaS platform, which relates to the field of data processing technology, including: obtaining a multi-tenant information layer based on a SaaS platform, obtaining a first permission set, the first permission set including one or more different permission types; defining a weight index, and generating a first identifier and a first weight value; obtaining a newly added tenant based on the SaaS platform, matching the role type and completing the permission configuration; setting a verification time period, obtaining a second permission set of the newly added tenant in real time at intervals of a verification time period, and generating a second weight value corresponding to the first tenant; judging whether the second weight value is the same as the first weight value, if not the same, reclaiming the tenant permission configuration, if the same, generating a second identifier corresponding to the first tenant; judging whether the second identifier is the same as the first identifier, if not the same, reclaiming the tenant permission configuration. The present invention has the advantages of accurate configuration, dynamic verification and strong security.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a multi-tenant permission configuration method, system, device and medium based on a SaaS platform. Background Art

[0002] With the vigorous development of cloud computing technology, the Software as a Service (SaaS) model has become the preferred solution for many enterprises' information construction due to its flexibility and cost-effectiveness. The SaaS platform provides software services through the cloud, allowing users to rent application functions on demand without having to bear the tediousness and cost of software purchase, installation and maintenance. Under the multi-tenant architecture, the SaaS platform can efficiently serve multiple tenants and achieve a high degree of resource sharing and utilization. However, this model also brings unprecedented challenges in permission management. In the multi-tenant environment of the SaaS platform, permission management is not only the key to ensuring data security and correct execution of business logic, but also the basis for maintaining platform stability and trust between tenants. However, the existing permission configuration methods often face many difficulties.

[0003] Due to the large number of tenants and their different business needs, configuring permissions for each tenant is inefficient and prone to errors. It is difficult to adapt to the rapid changes in tenant needs, resulting in frequent inconsistencies between the actual permissions of tenants and the permissions that should be configured. This inconsistency not only affects the normal use of tenants, but may also lead to serious consequences such as data leakage or business logic errors. At the same time, traditional permission management methods often lack effective monitoring and verification mechanisms, making it possible for tenants to tamper with their own permission configurations. Some tenants may arbitrarily increase or modify their own permissions for personal gain or misoperation, resulting in permission abuse and security risks. This permission tampering behavior not only violates the usage regulations of the SaaS platform, but may also threaten the data security and business operations of other tenants.

[0004] Therefore, it is necessary to study a new permission configuration method in order to optimize and improve the permission configuration in the multi-tenant environment of the SaaS platform, especially in solving the verification and monitoring of tenant permission configuration and preventing permission abuse. Summary of the invention

[0005] In view of the defects in the prior art, the present invention provides a multi-tenant permission configuration method, system, device and medium based on a SaaS platform.

[0006] A multi-tenant permission configuration method based on a SaaS platform includes: obtaining a multi-tenant information layer based on the SaaS platform, and obtaining a plurality of different role types and a first permission set corresponding to each role type according to the multi-tenant information layer, wherein the first permission set includes one or more different permission types; defining a weight index corresponding to each permission type, and generating a first identifier and a first weight value corresponding to the role type according to the weight index of the permission type in the first permission set corresponding to the role type; obtaining a new tenant based on the SaaS platform, matching the role type according to the new tenant, and completing the permission configuration according to the first permission set corresponding to the matched role type; setting a verification time period, obtaining a second permission set configured by the new tenant in real time at intervals of a verification time period, wherein the second permission set includes one or more different permission types, and generating a second weight value corresponding to the first tenant according to the weight index of the permission type in the second permission set corresponding to the new tenant; judging whether the second weight value is the same as the first weight value, and if not, revoking the tenant permission configuration, and if they are the same, generating a second identifier corresponding to the first tenant according to the weight index of the permission type in the second permission set corresponding to the new tenant; judging whether the second identifier is the same as the first identifier, and if not, revoking the tenant permission configuration.

[0007] Optionally, generating a first identifier and a first weight value corresponding to a role type based on a weight indicator of the permission type in the first permission set corresponding to the role type includes: generating a first identifier corresponding to the role type based on a hash calculation model and the weight indicator of the permission type in the first permission set corresponding to the role type; generating a first weight value corresponding to the role type based on a weight calculation model and the weight indicator of the permission type in the first permission set corresponding to the role type.

[0008] Optionally, generating a second weight value corresponding to the first tenant based on a weight index of a permission type in a second permission set corresponding to the newly added tenant includes: generating a second weight value corresponding to the first tenant based on a weight calculation model and a weight index of a permission type in the second permission set corresponding to the newly added tenant.

[0009] Optionally, if they are the same, generating a second identifier corresponding to the first tenant based on a weight index of the permission type in the second permission set corresponding to the newly added tenant includes: if they are the same, generating a second identifier corresponding to the first tenant based on a hash calculation model and a weight index of the permission type in the second permission set corresponding to the newly added tenant.

[0010] Optionally, the hash calculation model in the first identifier corresponding to the role type is generated based on the hash calculation model and the weight index of the permission type in the first permission set corresponding to the role type as represented by: ;in, is the first identifier corresponding to the j-th role type, is the number of permission types in the first permission set, is the salt value coefficient, is the weight index of the i-th permission type in the first permission set, To restrict prime numbers.

[0011] Optionally, the weight calculation model in generating the first weight value corresponding to the role type based on the weight calculation model and the weight index of the permission type in the first permission set corresponding to the role type is expressed as: ;in, is the first weight value corresponding to the j-th role type.

[0012] Optionally, defining weight indicators corresponding to each permission type includes: obtaining a business decision impact and a security risk indicator of the permission type; and obtaining a weight indicator according to the business decision impact and the security risk indicator.

[0013] A multi-tenant permission configuration system based on a SaaS platform is also provided, the system comprising: an acquisition module for acquiring a multi-tenant information layer based on the SaaS platform, and acquiring a plurality of different role types and a first permission set corresponding to each role type according to the multi-tenant information layer, wherein the first permission set comprises one or more different permission types; a definition and calculation module for defining a weight index corresponding to each permission type, and generating a first identifier and a first weight value corresponding to the role type according to the weight index of the permission type in the first permission set corresponding to the role type; a permission configuration module for acquiring a newly added tenant based on the SaaS platform, and matching the role type according to the newly added tenant and matching the first permission set corresponding to the matched role type Complete the permission configuration; a verification calculation module is used to set a verification time period, and obtain the second permission set configured by the newly added tenant in real time at intervals of a verification time period. The second permission set includes one or more different permission types, and generates a second weight value corresponding to the first tenant based on the weight index of the permission type in the second permission set corresponding to the newly added tenant; a first comparison module is used to determine whether the second weight value is the same as the first weight value. If they are not the same, the tenant's permission configuration is revoked. If they are the same, a second identifier corresponding to the first tenant is generated based on the weight index of the permission type in the second permission set corresponding to the newly added tenant; a second comparison module is used to determine whether the second identifier is the same as the first identifier. If they are not the same, the tenant's permission configuration is revoked.

[0014] An electronic device is also provided, comprising: a memory on which a computer program is stored; and a processor for executing the computer program in the memory to implement the above-mentioned multi-tenant permission configuration method based on the SaaS platform.

[0015] A non-temporary computer-readable storage medium is also provided, on which a computer program is stored, and when the program is executed by a processor, the multi-tenant permission configuration method based on the SaaS platform is implemented.

[0016] The beneficial effects of the present invention are embodied in:

[0017] In the entire multi-tenant permission configuration method based on the SaaS platform, the role type is subdivided according to the tenant information layer and the corresponding first permission set is defined, which lays a clear basic framework for permission management; then, by setting weight indicators for each permission type and generating the first weight value and the first identifier, a quantitative standard and a reliable basis are provided for the verification of permission configuration; further, when adding a new tenant, the role type can be intelligently matched and the permission can be automatically configured, which greatly improves the configuration efficiency; further, through the periodic double verification of weight values ​​and identifiers, the abnormalities in the permission configuration can be discovered and corrected in time, effectively preventing the tenant from tampering with the permission or the security problems caused by configuration errors, thereby ensuring the correctness of the tenant's permissions, the security of the data and the stability of the platform business, and providing a solid and reliable permission management guarantee for the multi-tenant environment of the SaaS platform; further, in the verification process, the first weight value is verified first. The design of this step is based on the consideration that the weight value verification requires less computing power and faster speed than the identifier verification. Through this strategy, data that does not meet the requirements or has low weight can be quickly screened out in the early stage, thereby avoiding unnecessary subsequent verification overhead. This "weight first, then identifier" verification order greatly improves the efficiency of the overall verification process and reduces the waste of computing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for the specific embodiments or the description of the prior art. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn according to the actual scale.

[0019] Figure 1 A schematic diagram of the steps of the multi-tenant permission configuration method based on the SaaS platform of the present invention;

[0020] Figure 2 This is a schematic diagram of a portion of steps S2 in the multi-tenant permission configuration method based on the SaaS platform of the present invention;

[0021] Figure 3 It is a schematic diagram of some steps of S4 in the multi-tenant permission configuration method based on the SaaS platform of the present invention;

[0022] Figure 4It is a schematic diagram of some steps of S5 in the multi-tenant permission configuration method based on the SaaS platform of the present invention;

[0023] Figure 5 This is another schematic diagram of steps S2 in the multi-tenant permission configuration method based on the SaaS platform of the present invention;

[0024] Figure 6 The present invention is a block diagram of an electronic device according to an embodiment of the present invention.

[0025] Reference numerals:

[0026] 700 - electronic device, 701 - processor, 702 - memory, 703 - multimedia component, 704 - input / output (I / O) interface, 705 - communication component. DETAILED DESCRIPTION

[0027] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings here can be arranged and designed in various different configurations.

[0028] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention claimed for protection, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0029] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings. In addition, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0030] like Figure 1 As shown, a multi-tenant permission configuration method based on a SaaS platform is provided, including:

[0031] S1. Obtain a multi-tenant information layer based on the SaaS platform, and obtain a plurality of different role types and a first permission set corresponding to each role type according to the multi-tenant information layer, wherein the first permission set includes one or more different permission types;

[0032] S2. Define a weight index corresponding to each permission type, and generate a first identifier and a first weight value corresponding to the role type according to the weight index of the permission type in the first permission set corresponding to the role type;

[0033] S3. Acquire a new tenant based on the SaaS platform, match the role type according to the new tenant, and complete the permission configuration according to the first permission set corresponding to the matched role type;

[0034] S4. Setting a verification time period, obtaining in real time a second permission set configured by the newly added tenant at each verification time period, wherein the second permission set includes one or more different permission types, and generating a second weight value corresponding to the first tenant according to a weight index of the permission type in the second permission set corresponding to the newly added tenant;

[0035] S5. Determine whether the second weight value is the same as the first weight value. If they are not the same, revoke the tenant's permission configuration. If they are the same, generate a second identifier corresponding to the first tenant according to the weight index of the permission type in the second permission set corresponding to the newly added tenant;

[0036] S6. Determine whether the second identifier is the same as the first identifier. If they are not the same, revoke the tenant permission configuration.

[0037] In this embodiment, it should be noted that in S1, the core is to extract the multi-tenant information layer through the SaaS platform, and then subdivide different role types, and define a set of specific permission sets for each role type, namely the first permission set. Specifically, the SaaS platform will first extract the multi-tenant information layer, which is responsible for the management and configuration of tenants, including the creation, deletion, modification and personalization of tenants; then obtain different role types through the multi-tenant information layer, including "ordinary user", "administrator", "senior administrator", etc. These role types reflect the different identities and responsibilities of different tenants on the platform; next, a corresponding first permission set will be assigned to each role type. This permission set is composed of a series of specific permission types, such as "view data", "edit data", "delete data", "manage users", etc. These permission types refine the role's operating permissions on the platform. For example, for the "ordinary user" role, its first permission set may only include the permission of "view data"; while for the "administrator" role, its first permission set may include multiple permissions such as "view data", "edit data" and "manage users". These permission sets are the basis for subsequent permission configuration, verification and monitoring.

[0038] Assume that a SaaS platform serves multiple objects, each of which is a tenant. For example, a tenant is a sales role (responsible for sales management-related matters), a finance role (responsible for finance-related operations), and a digestion role (responsible for digesting business needs). Then, the platform defines the first permission set for each of these roles: the sales role may have permissions to view sales data, edit sales orders, etc.; the finance role may have permissions to view financial statements, conduct financial audits, etc.; the digestion role has permissions to view digestion orders, edit digestion orders, and upload demand files, etc. In this way, each role has a clear scope of permissions, providing a clear basic framework for subsequent permission configuration and management.

[0039] In S2, the core is to set specific weight indicators for each permission type, and generate a unique first identifier and a corresponding first weight value for each role type based on these weight indicators. Specifically, the weight of each permission type will be defined in detail first, and this weight is usually determined based on the importance, sensitivity, and impact of the permission on the business logic. For example, permissions that can directly access or modify core data, such as "edit financial data", will be given a higher weight; while permissions that are only used to view non-sensitive information, such as "view company news", will be given a lower weight. Next, the sum of the weights of all permission types in the first permission set corresponding to each role type will be calculated, and this sum is the first weight value of the role type. At the same time, a unique first identifier will be generated based on the weights of these permission types and a specific algorithm (such as a hash algorithm). This identifier is equivalent to the "fingerprint" of the permission configuration of the role type, which is used to quickly and accurately verify the correctness of the permission configuration in the future.

[0040] Taking the actual SaaS platform as an example, weight indicators of three types of permissions are defined: "View data" (weight 1), "Edit data" (weight 5), and "Manage users" (weight 10). For the "ordinary user" role, its first permission set only includes the "view data" permission, so its first weight value is 1, and the first identifier generated based on this permission set will also be unique, assuming it is "ID_PU_1". For the "administrator" role, its first permission set includes the three permissions of "view data", "edit data" and "manage users", so its first weight value is the sum of the weights of these three permissions, that is, 1+5+10=16. Similarly, a specific algorithm (such as a hash algorithm) generates a unique first identifier, which is generally a unique string.

[0041] In S3, the core is to match new tenants with predefined role types, and automatically configure the corresponding permission sets for the tenants based on the matching results. Specifically, when the SaaS platform welcomes a new tenant, it will first collect the basic information of the tenant, including but not limited to the tenant's industry attributes, business scale, purpose of use, etc. Then, based on this information and the existing role type definitions in the platform, the new tenants will be classified into the most appropriate role type through an intelligent matching algorithm. This matching process may involve multi-dimensional considerations, such as determining which specific operating permissions the tenant needs based on the tenant's business needs, or evaluating the tenant's requirements for data sensitivity based on the tenant's industry characteristics. Once the match is completed, the corresponding permissions will be automatically configured for the new tenant based on the first permission set corresponding to the selected role type, thereby ensuring that the tenant can quickly and accurately obtain all the permissions required to conduct business.

[0042] Taking an actual SaaS platform as an example, suppose a new tenant is added to the platform. The tenant is a company focused on e-commerce, and its main business is to sell goods online. In the S3 step, basic information about the company is first collected, such as company size, main business, and intended purpose of using the platform. Then, this information is analyzed and compared with the predefined role types in the platform. In this process, it may be found that the company best meets the definition of a "sales role" because this role type usually includes permissions related to the sale of goods, such as viewing sales data and managing product information. Therefore, the first permission set corresponding to the "sales role" is automatically configured for this new tenant, including permissions such as viewing sales data and editing sales orders. In this way, new tenants can quickly integrate into the platform and start their online sales business without having to manually configure complex permission settings.

[0043] In S4, the core is to ensure that the permission configuration of the newly added tenants is consistent with the preset role type permission set by periodically checking it. Specifically, a verification time period will be set, and this period can be flexibly adjusted according to the actual needs of the platform, such as daily, weekly or monthly. Whenever the verification time point is reached, the verification process will be automatically triggered. First, the second permission set currently configured by the newly added tenant is obtained in real time. This set contains all the permission types that the tenant has during actual use. Then, according to the predefined permission type weight index, the sum of the weights of the second permission set of the newly added tenant is calculated to generate the corresponding second weight value. The purpose of this step is to preliminarily determine whether there is an abnormality in the tenant's permission configuration through comparison of the weight values, that is, whether it is inconsistent with the permission set that his role type should have.

[0044] Assume that the verification time period set by the SaaS platform is once a week. When a certain verification period arrives, step S4 is executed to perform permission verification on a newly added e-commerce company tenant. First, the second permission set currently configured by the tenant is obtained. For example, it is found that the tenant has the permission to view sales data, edit sales orders, and view company news. Then, the second weight value of the second permission set of the tenant is calculated based on the preset permission type weight indicators, such as "view data" (weight 1) and "edit data" (weight 5). Assuming that the weight of "view company news" is 1, the second weight value of the tenant is 1 (view sales data) + 5 (edit sales orders) + 1 (view company news) = 7. Next, in S5, this second weight value will be compared with the first weight value corresponding to the "sales role" to determine whether the tenant's permission configuration is correct.

[0045] In S5, the core is to determine whether the tenant's permission configuration is correct by comparing the second weight value of the newly added tenant with the first weight value of the corresponding role type. Specifically, after completing step S4, that is, calculating the second weight value of the newly added tenant, this second weight value will be compared with the first weight value of the role type matched by the tenant. If the two weight values ​​are the same, it means that the tenant's permission configuration may be consistent with the preset permission type, and there is no abnormality, but there may be different permission types with the same weight index. Therefore, after confirming that the second weight value is the same as the first weight value, the second identifier will be generated according to the permission type and its weight index in the second permission set currently configured by the newly added tenant, using the same algorithm as the first identifier (such as a hash algorithm). The second identifier is the unique "fingerprint" of the tenant's current permission configuration. Subsequently, the second identifier will be compared with the first identifier of the role type matched by the tenant. If the two weight values ​​are different, it means that there may be a problem with the tenant's permission configuration. The tenant may have modified the permission configuration without authorization, or an error occurred during the permission configuration. In this case, the tenant's permission configuration will be immediately revoked, that is, all permissions currently held by the tenant will be revoked, and the permission configuration will be reconfigured as needed to ensure the correctness and security of the tenant's permissions.

[0046] Assume that in a certain verification cycle, a permission verification is performed on a tenant of an e-commerce company. In S4, the second weight value of the tenant has been calculated to be 7. Next, in S5, this second weight value will be compared with the first weight value corresponding to the "sales role". The first weight value of the "sales role" is calculated based on the preset permission type weight index and the permission set that the "sales role" should have, which is assumed to be 6 (because the "sales role" usually does not include the permission to "view company news"). Since the second weight value of 7 of the tenant is inconsistent with the first weight value of 6 of the "sales role", it is judged that there is a problem with the permission configuration of the tenant. Therefore, the permission configuration of the tenant will be revoked immediately, that is, the permission to view sales data, edit sales orders, and view company news will be revoked, and the permissions for the tenant will be reconfigured according to the permission set of the "sales role" to ensure the correctness and security of its permission configuration.

[0047] In S6, the core is to finally confirm whether the tenant's permission configuration is correct and has not been tampered with by comparing the second identifier of the newly added tenant with the first identifier of the corresponding role type. In step S5, although the tenant's permission configuration has been preliminarily judged by comparing the weight values ​​whether there are any anomalies, the same weight value cannot completely guarantee the consistency of the permission configuration, because there may be different permission combinations with the same weight sum. Therefore, S6 provides a more accurate and reliable verification method by comparing the first identifier and the second identifier. If the second identifier is the same as the first identifier, it means that the tenant's permission configuration is completely consistent with the preset role type permission set in terms of permission type, weight and combination method, and there is no tampering or anomaly. At this time, the tenant will be allowed to continue to maintain the current permission configuration to ensure that it can carry out business normally. If the second identifier is different from the first identifier, it means that the tenant's permission configuration has been tampered with to some extent. Regardless of whether the tampering is due to the tenant's self-interest or misoperation, the tenant's permission configuration will be immediately revoked, that is, all permissions currently owned by the tenant will be revoked, and the permission configuration will be reconfigured as needed to ensure that the stability of the platform and the foundation of trust between tenants are not destroyed. In this way, through the double verification mechanism, the correctness and security of the tenant's permission configuration can be more accurately ensured.

[0048] In summary, in the entire multi-tenant permission configuration method based on the SaaS platform, the role type is subdivided according to the tenant information layer and the corresponding first permission set is defined, which lays a clear basic framework for permission management; then, by setting weight indicators for each permission type and generating the first weight value and the first identifier, a quantitative standard and a reliable basis are provided for the verification of permission configuration; further, when adding a new tenant, the role type can be intelligently matched and the permission can be automatically configured, which greatly improves the configuration efficiency; further, through the periodic double verification of the weight value and the identifier, the abnormalities in the permission configuration can be discovered and corrected in time, effectively preventing the tenant from tampering with the permission or the security problems caused by the configuration error, thereby ensuring the correctness of the tenant's permission, the security of the data and the stability of the platform business, and providing a solid and reliable permission management guarantee for the multi-tenant environment of the SaaS platform; further, in the verification process, the first weight value is verified first. The design of this step is based on the consideration that the weight value verification requires less computing power and faster speed than the identifier verification. Through this strategy, data that does not meet the requirements or has low weight can be quickly screened out at an early stage, thereby avoiding unnecessary subsequent verification overhead. This verification order of "weight first, then identifier" greatly improves the efficiency of the overall verification process and reduces the waste of computing resources.

[0049] like Figure 2 As shown, in one embodiment, generating a first identifier and a first weight value corresponding to the role type according to a weight index of the permission type in the first permission set corresponding to the role type in S2 includes:

[0050] S23, generating a first identifier corresponding to the role type based on the hash calculation model and the weight index of the permission type in the first permission set corresponding to the role type;

[0051] S24: Generate a first weight value corresponding to the role type based on the weight calculation model and the weight index of the permission type in the first permission set corresponding to the role type.

[0052] In this embodiment, it should be noted that in S23, the first identifier corresponding to the role type is generated based on the hash calculation model and the weight index of the permission type in the first permission set corresponding to the role type. This process first involves an in-depth analysis of the first permission set of the role type. Each permission type is assigned a specific weight index based on factors such as its importance, frequency of use or security level. Subsequently, these weight indicators are sent to the hash calculation model as input information. The hash calculation model is an algorithm that can convert input data of any length into an output (i.e., an identifier) ​​of a fixed length. In this scenario, the model will comprehensively consider the weights of each permission type, and through complex calculation processes, such as bit operations, iterative processing, etc., a unique first identifier is generated. This first identifier represents the unique identity of the role type and also implies the characteristic information of its permission set.

[0053] In S24, the weight calculation model is used to generate the first weight value corresponding to the role type according to the weight index of the permission type in the first permission set corresponding to the role type. The core of this step is to quantitatively evaluate the weight index of the permission set. The weight calculation model may use weighted average, hierarchical analysis method or other mathematical statistical methods to comprehensively consider the weight size of each permission type and its influence on the overall permission set. Specifically, the model will traverse each permission in the first permission set, perform weighted processing according to its weight index, and finally summarize it to obtain a comprehensive weight value. This weight value not only reflects the relative importance of the role type in the permission system, but also provides a quantitative basis for subsequent permission management, access control and other decisions. Through this processing method, the permission differences of different role types can be described and managed more finely and accurately.

[0054] like Figure 3 As shown, in one embodiment, generating a second weight value corresponding to the first tenant according to a weight index of a permission type in a second permission set corresponding to the newly added tenant in S4 includes:

[0055] S41. Generate a second weight value corresponding to the first tenant based on a weight calculation model and a weight index of a permission type in a second permission set corresponding to the newly added tenant.

[0056] In this embodiment, it should be noted that in S41, a detailed description is given of the generation of the second weight value corresponding to the first tenant based on the weight calculation model and the weight index of the permission type in the second permission set corresponding to the newly added tenant. This process first requires a comprehensive sorting of the permission set owned by the newly added tenant, in which each permission type will correspond to the weight index defined in S2. Then, these weight indexes will be sent to the weight calculation model as input data. The model may use complex algorithms, such as weighted average method, hierarchical analysis method or fuzzy comprehensive evaluation method, to perform in-depth analysis and quantitative processing on the input weight index. The model will comprehensively consider the weight size of each permission type and their relationship with each other, and through a series of mathematical operations, it will eventually output a comprehensive weight value, that is, the second weight value corresponding to the first tenant. This second weight value not only accurately reflects the relative position and importance of the newly added tenant in the permission system, but also provides a scientific basis for subsequent decisions such as permission allocation and access control.

[0057] like Figure 4 As shown, in one embodiment, if the two are the same, generating the second identifier corresponding to the first tenant according to the weight index of the permission type in the second permission set corresponding to the newly added tenant in S5 includes:

[0058] S51: If they are the same, generate a second identifier corresponding to the first tenant based on the hash calculation model and the weight index of the permission type in the second permission set corresponding to the newly added tenant.

[0059] In this embodiment, it should be noted that in S51, it is elaborated in detail that when it is confirmed that the first weight value of the newly added tenant is the same as the first weight value of the existing tenant, the second identifier corresponding to the first tenant is generated based on the hash calculation model and the weight index of the permission type in the second permission set corresponding to the newly added tenant. First, the second permission set of the newly added tenant will be checked, and each permission type in the set will correspond to the weight index defined in S2. Subsequently, these weight indicators are sent to the hash calculation model as input data. The hash calculation model is a mathematical algorithm that can convert input data of any length (here is the weight index of the permission type) into a fixed-length, unique output value, that is, a hash value or identifier. Finally, a second identifier corresponding to the characteristics of the permission set of the newly added tenant is generated. This identifier not only uniquely identifies the newly added tenant, but also implies specific information of its permission set, providing guidance for subsequent management, permission control, etc.

[0060] In one embodiment, the hash calculation model in the first identifier corresponding to the role type generated based on the hash calculation model and the weight index of the permission type in the first permission set corresponding to the role type in S23 is expressed as:

[0061] ;in,

[0062] is the first identifier corresponding to the j-th role type, is the number of permission types in the first permission set, is the salt value coefficient, is the weight index of the i-th permission type in the first permission set, To restrict prime numbers.

[0063] In this embodiment, it should be noted that It is the first identifier corresponding to the j-th role type. The identifier is unique and is used to distinguish different role types and implies the characteristic information of their permission sets. The weight indicators representing the first to the nth permission types are taken into account, which ensures that the contribution of each permission type to the final identifier is calculated. This is the salt coefficient, which is a random or preset value. It is directly associated with the permission type and has nothing to do with the weight indicator. It can ensure that the identifiers generated by different permission types are completely different. It can also be used to increase the complexity and unpredictability of the hash value, which can improve security and prevent rainbow table attacks. This is the square of the weight index of the i-th permission type in the first permission set. Squaring the weight index can amplify its difference, making the contribution of permission types with larger weights more significant in the final identifier, which helps to distinguish permission sets of different role types even if their permission types partially overlap. It is a modular operation, which means taking the remainder after dividing the previous sum by the restricted prime number M. Modular operation is a commonly used method for constructing hash functions. It can ensure that the length of the output value (i.e., the identifier) ​​is fixed and limited to between 0 and M-1. The prime number M is chosen as the modulus to reduce the possibility of hash conflicts, because prime numbers have unique properties in number theory, which can make the hash value distribution more uniform.

[0064] In one embodiment, the weight calculation model in generating the first weight value corresponding to the role type based on the weight calculation model and the weight index of the permission type in the first permission set corresponding to the role type in S24 is expressed as:

[0065] ;in,

[0066] is the first weight value corresponding to the j-th role type.

[0067] In this embodiment, it should be noted that Indicates the first weight value corresponding to the j-th role type. Indicates that the weights of the first to the nth permission types will be accumulated. is the weight index of the i-th permission type, which directly reflects the importance of this permission type in the role type.

[0068] In summary, the first weight value of the role type is generated by directly accumulating the weight index of the permission type. It has the advantages of high computational efficiency, easy understanding, flexibility and accuracy, and is suitable for scenarios where weight values ​​need to be generated quickly and accurately.

[0069] like Figure 5 As shown, in one embodiment, the weight indicators corresponding to each permission type defined in S2 include:

[0070] S21. Business decision impact and security risk indicators of the access permission type;

[0071] S22. Obtain weight indicators based on business decision impact and security risk indicators.

[0072] In this embodiment, it should be noted that in S21, it is first necessary to obtain the business decision impact and security risk indicators of each permission type. Business decision impact refers to the degree of influence of this permission type on the business decision process and results. For example, in enterprise management, the permission type of modifying financial data may have a high business decision impact because it is directly related to the financial status and decision-making of the enterprise. The security risk indicator refers to the security risk that may be caused if this permission type is abused or misused. This includes potential risks such as data leakage, unauthorized access, and crashes. In order to obtain these indicators, it may be necessary to refer to multiple sources such as industry standards, historical data, expert opinions, and conduct comprehensive analysis and evaluation.

[0073] In S22, after obtaining the business decision impact and security risk indicators of each permission type, it is necessary to calculate the weight indicator based on these indicators. The weight indicator is a quantitative value that reflects the relative importance of each permission type in the overall permission system. When calculating the weight indicator, you can consider weighted summing the business decision impact and security risk indicators or using other appropriate algorithms. For example, a higher weight can be given to the business decision impact because it is directly related to the core business and operations of the enterprise; and the security risk indicator can be given a corresponding weight according to the severity of its potential risks. Through such a calculation process, an accurate weight indicator can be generated for each permission type, providing strong support for subsequent permission allocation and access control.

[0074] A multi-tenant permission configuration system based on a SaaS platform is also provided, the system comprising:

[0075] An acquisition module, configured to acquire a multi-tenant information layer based on a SaaS platform, and acquire a plurality of different role types and a first permission set corresponding to each role type according to the multi-tenant information layer, wherein the first permission set includes one or more different permission types;

[0076] A definition and calculation module, used to define weight indicators corresponding to each permission type, and generate a first identifier and a first weight value corresponding to the role type according to the weight indicators of the permission types in the first permission set corresponding to the role type;

[0077] The permission configuration module is used to obtain a new tenant based on the SaaS platform, match the role type according to the new tenant, and complete the permission configuration according to the first permission set corresponding to the matched role type;

[0078] A verification calculation module, used to set a verification time period, obtain a second permission set configured by the newly added tenant in real time at each verification time period, wherein the second permission set includes one or more different permission types, and generate a second weight value corresponding to the first tenant according to a weight index of the permission type in the second permission set corresponding to the newly added tenant;

[0079] A first comparison module is used to determine whether the second weight value is the same as the first weight value, and if not, to revoke the tenant's permission configuration; if they are the same, to generate a second identifier corresponding to the first tenant according to the weight index of the permission type in the second permission set corresponding to the newly added tenant;

[0080] The second comparison module is used to determine whether the second identifier is the same as the first identifier, and if they are not the same, the tenant authority configuration is revoked.

[0081] In this embodiment, it should be noted that regarding the above-mentioned multi-tenant permission configuration system based on the SaaS platform, the specific method of performing operations has been described in detail in the implementation method of the multi-tenant permission configuration method based on the SaaS platform, and will not be elaborated here.

[0082] Figure 6 1 is a block diagram of an electronic device showing a multi-tenant permission configuration method based on a SaaS platform according to an exemplary embodiment. Figure 6 As shown, the electronic device 700 may include: a processor 701 , a memory 702 . The electronic device 700 may also include one or more of a multimedia component 703 , an input / output (I / O) interface 704 , and a communication component 705 .

[0083] The processor 701 is used to control the overall operation of the electronic device 700 to complete all or part of the steps in the multi-tenant permission configuration method based on the SaaS platform. The memory 702 is used to store various types of data to support the operation of the electronic device 700, and these data may include, for example, instructions for any application or method used to operate on the electronic device 700, and application-related data, such as contact data, sent and received messages, pictures, audio, video, etc. The memory 702 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (Static Random Access Memory, referred to as SRAM), electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, referred to as EEPROM), erasable programmable read-only memory (Erasable Programmable Read-Only Memory, referred to as EPROM), programmable read-only memory (Programmable Read-Only Memory, referred to as PROM), read-only memory (Read-Only Memory, referred to as ROM), magnetic memory, flash memory, disk or optical disk. The multimedia component 703 may include a screen and an audio component. The screen may be, for example, a touch screen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone, which is used to receive external audio signals. The received audio signal may be further stored in the memory 702 or sent through the communication component 705. The audio component also includes at least one speaker for outputting audio signals. The I / O interface 704 provides an interface between the processor 701 and other interface modules, and the above-mentioned other interface modules may be keyboards, mice, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 705 is used for wired or wireless communication between the electronic device 700 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IOT, eMTC or other 5G, etc., or a combination of one or more of them, is not limited here. Therefore, the corresponding communication component 705 may include: Wi-Fi module, Bluetooth module, NFC module, etc.

[0084] In an exemplary embodiment, the electronic device 700 can be implemented by one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), controllers, microcontrollers, microprocessors or other electronic components to execute the above-mentioned multi-tenant permission configuration method based on the SaaS platform.

[0085] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, and when the program instructions are executed by a processor, the steps of the multi-tenant permission configuration method based on the SaaS platform are implemented. For example, the computer-readable storage medium can be the memory 702 including the program instructions, and the program instructions can be executed by the processor 701 of the electronic device 700 to complete the multi-tenant permission configuration method based on the SaaS platform.

[0086] In another exemplary embodiment, a computer program product is also provided, which includes a computer program that can be executed by a programmable device, and the computer program has a code portion for executing the above-mentioned multi-tenant permission configuration method based on the SaaS platform when executed by the programmable device.

[0087] The preferred embodiments of the present disclosure are described in detail above in conjunction with the accompanying drawings; however, the present disclosure is not limited to the specific details in the above embodiments. Within the technical concept of the present disclosure, a variety of simple modifications can be made to the technical solution of the present disclosure, and these simple modifications all fall within the protection scope of the present disclosure.

[0088] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, the present disclosure will not further describe various possible combinations.

[0089] In addition, various embodiments of the present disclosure may be arbitrarily combined, and as long as they do not violate the concept of the present disclosure, they should also be regarded as the contents disclosed by the present disclosure.

[0090] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. These modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be included in the scope of the claims and specification of the present invention.

Claims

1. A multi-tenant permission configuration method based on a SaaS platform, characterized in that: include: Acquire a multi-tenant information layer based on the SaaS platform, and acquire a plurality of different role types and a first permission set corresponding to each role type according to the multi-tenant information layer, wherein the first permission set includes one or more different permission types; Defining weight indicators corresponding to each permission type, and generating a first identifier and a first weight value corresponding to the role type according to the weight indicators of the permission types in the first permission set corresponding to the role type; Wherein, generating the first identifier and the first weight value corresponding to the role type according to the weight index of the permission type in the first permission set corresponding to the role type comprises: generating the first identifier corresponding to the role type based on the hash calculation model and the weight index of the permission type in the first permission set corresponding to the role type; generating the first weight value corresponding to the role type based on the weight calculation model and the weight index of the permission type in the first permission set corresponding to the role type; The hash calculation model in the first identifier corresponding to the role type generated based on the hash calculation model and the weight index of the permission type in the first permission set corresponding to the role type is expressed as: ;in, is the first identifier corresponding to the j-th role type, is the number of permission types in the first permission set, is the salt value coefficient, is the weight index of the i-th permission type in the first permission set, To restrict prime numbers; The weight calculation model in generating the first weight value corresponding to the role type based on the weight calculation model and the weight index of the permission type in the first permission set corresponding to the role type is expressed as: ;in, is the first weight value corresponding to the j-th role type; Acquire a new tenant based on the SaaS platform, match the role type according to the new tenant, and complete the permission configuration according to the first permission set corresponding to the matched role type; A verification time period is set, and a second permission set configured by the newly added tenant is obtained in real time at each verification time period, where the second permission set includes one or more different permission types, and a second weight value corresponding to the first tenant is generated according to a weight index of the permission type in the second permission set corresponding to the newly added tenant; Determine whether the second weight value is the same as the first weight value, if not, revoke the tenant's permission configuration; if they are the same, generate a second identifier corresponding to the first tenant according to the weight index of the permission type in the second permission set corresponding to the newly added tenant; Determine whether the second identifier is the same as the first identifier, and if not, revoke the tenant permission configuration.

2. The multi-tenant permission configuration method based on the SaaS platform according to claim 1 is characterized in that: Generating the second weight value corresponding to the first tenant according to the weight index of the permission type in the second permission set corresponding to the newly added tenant includes: A second weight value corresponding to the first tenant is generated based on the weight calculation model and the weight index of the permission type in the second permission set corresponding to the newly added tenant.

3. The multi-tenant permission configuration method based on the SaaS platform according to claim 1 is characterized in that: If they are the same, generating a second identifier corresponding to the first tenant according to a weight index of the permission type in the second permission set corresponding to the newly added tenant includes: If they are the same, a second identifier corresponding to the first tenant is generated based on the hash calculation model and the weight index of the permission type in the second permission set corresponding to the newly added tenant.

4. The multi-tenant permission configuration method based on the SaaS platform according to claim 1 is characterized in that: The weight indicators corresponding to the definition of each permission type include: The business decision impact and security risk indicators of the access permission type; Obtain weight indicators based on business decision impact and security risk indicators.

5. A multi-tenant permission configuration system based on a SaaS platform, characterized in that: The system comprises: An acquisition module, configured to acquire a multi-tenant information layer based on a SaaS platform, and acquire a plurality of different role types and a first permission set corresponding to each role type according to the multi-tenant information layer, wherein the first permission set includes one or more different permission types; A definition and calculation module, used to define weight indicators corresponding to each permission type, and generate a first identifier and a first weight value corresponding to the role type according to the weight indicators of the permission types in the first permission set corresponding to the role type; The definition and calculation module is further used to: generate a first identifier corresponding to the role type based on the hash calculation model and the weight index of the permission type in the first permission set corresponding to the role type; generate a first weight value corresponding to the role type based on the weight calculation model and the weight index of the permission type in the first permission set corresponding to the role type; The hash calculation model in the first identifier corresponding to the role type generated based on the hash calculation model and the weight index of the permission type in the first permission set corresponding to the role type is expressed as: ;in, is the first identifier corresponding to the j-th role type, is the number of permission types in the first permission set, is the salt value coefficient, is the weight index of the i-th permission type in the first permission set, To restrict prime numbers; The weight calculation model in generating the first weight value corresponding to the role type based on the weight calculation model and the weight index of the permission type in the first permission set corresponding to the role type is expressed as: ;in, is the first weight value corresponding to the j-th role type; The permission configuration module is used to obtain a new tenant based on the SaaS platform, match the role type according to the new tenant, and complete the permission configuration according to the first permission set corresponding to the matched role type; A verification calculation module, used to set a verification time period, obtain a second permission set configured by the newly added tenant in real time at each verification time period, wherein the second permission set includes one or more different permission types, and generate a second weight value corresponding to the first tenant according to a weight index of the permission type in the second permission set corresponding to the newly added tenant; A first comparison module is used to determine whether the second weight value is the same as the first weight value, and if not, to revoke the tenant's permission configuration; if they are the same, to generate a second identifier corresponding to the first tenant according to the weight index of the permission type in the second permission set corresponding to the newly added tenant; The second comparison module is used to determine whether the second identifier is the same as the first identifier, and if they are not the same, the tenant authority configuration is revoked.

6. An electronic device, characterized in that: include: a memory having a computer program stored thereon; A processor, configured to execute the computer program in the memory to implement the multi-tenant permission configuration method based on the SaaS platform as described in any one of claims 1 to 4.

7. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the multi-tenant permission configuration method based on the SaaS platform described in any one of claims 1 to 4 is implemented.

Images